Sven M.'s questions

Atualmente estou modelando um esquema de banco de dados. Nele, os endereços são utilizados várias vezes, que seguem uma estrutura fixa. Em nossos sistemas anteriores, a relação de endereço era modelada de tal forma que o endereço continha chaves estrangeiras, por exemplo, as de um usuário.

Raciocínio: Desta forma, um endereço só pode ser anexado a um dos pais. Do meu ponto de vista, no entanto, isso é um caos absoluto, porque às vezes existem até oito chaves estrangeiras na relação de endereço, devendo-se tomar cuidado para que apenas uma seja preenchida.

Não faria muito mais sentido colocar a chave no pai, de modo que, por meio de uma restrição diferente de zero, se pudesse garantir que cada pai tenha um endereço e a relação de endereço seja limpa? O pai também raramente/nunca é navegado a partir do lado do endereço.

Ou estou violando alguma convenção fazendo isso? Nesse caso, a limpeza não pesa mais do que uma "convenção"? Se desejado, também pode-se modelar os requisitos anteriores usando gatilhos?

Abordagem atual: Restrição para garantir que apenas um FK seja definido no endereço.

Minha abordagem: address_id como FK nos pais.

Eu li o seguinte post Como você modela efetivamente a herança em um banco de dados? sobre herança em bancos de dados. Infelizmente não encontrei nada nos livros PostgreSQL da Packt. E agora estou um pouco confuso se minha abordagem é um exagero e nem pertence ao banco de dados ou faz sentido (veja minhas considerações no final).

Primeiro eu queria implementar o exemplo a seguir usando Table-Per-Concrete . Mas então eu li várias vezes que você só deve fazer isso quando realmente tiver problemas de desempenho e deve usar tabela por tipo desde que não tenha problemas de desempenho.

Assim, as seguintes relações são dadas:

system_user (system_user_id, type, first_name, last_name, ...)

user (system_user_id) *Has no unique attributes but special relations accessible only for him, e.g. orders
customer (system_user_id, company_name, ...)
supporter (system_user_id, nickname, ...)

Até agora tudo bem, mas eu queria saber como garantir no exemplo acima que:

• O tipo não pode ser alterado.
• Um system_user tem no máximo uma entrada em uma extensão.

Minha consideração:

• Um gatilho que gera um erro se o tipo for alterado durante um UPDATE.
• Um gatilho para cada ramal, que verifica antes de um INSERT, se já existe uma entrada com este system_user_id em outro ramal.

Isso faz sentido? Ou estou indo do jeito errado? Isso é mesmo necessário? Devo criar uma relação separada para cada entidade diretamente?

Talvez eu tenha uma visão de desenvolvedor de software orientada a objetos demais. Muito obrigado por suas respostas.

O PostgreSQL possui variáveis ​​em nível de transação? Se não, é possível implementar algo assim com relativa facilidade? Infelizmente, ainda sou relativamente inexperiente com o PostgreSQL e só descobri que você pode definir configurações no nível da sessão.

Atualmente estou tentando implementar uma historização como o Hibernate tem diretamente no PostgreSQL. Uma informação curta para a qual eles não sabem Hibernate: Hibernate tem uma tabela para revisões. Ele contém um ID, a hora e outras informações. Para cada tabela existe uma tabela "_AUD". Cada alteração na mesma transação obtém o mesmo ID de revisão.

Para implementar isso diretamente no PostgreSQL, eu precisaria de uma variável que eu pudesse usar dentro de uma transação e cujo valor só pudesse ser usado dentro da mesma transação . Minha ideia é que toda vez que uma transação é historiada, uma função consulta se existe um ID para a transação, caso contrário, ela cria um, caso contrário retorna o já criado.

Eu uso a versão mais recente do PostgreSQL.