Como evitar registros órfãos em detalhe tabelas de banco de dados normalizado?

Question

Eu tenho que manter um banco de dados antigo, que não está devidamente normalizado. Por exemplo, há uma tabela de projeto que tem crescido (ou talvez multiplicaram) ter 5 ou mais diferentes colunas de data, para diferentes marcos do projeto de ser condenada a data de entrega. Há também várias tabelas cada um com colunas para endereços, endereços de e-mail ou links da Web.

Gostaria de normalizar a estrutura, criar tabelas de endereços, datas programadas e similares, e as tabelas necessárias para permitir a 1:. Relações N (endereço por cliente, data de vencimento por projeto e assim por diante)

Agora eu estou completamente sem saber como lidar com as alterações aos dados nas tabelas de detalhes. Considere, por exemplo, a mudança de um endereço de entrega do cliente. Alterar os dados na tabela de endereços está fora de questão, porque mais de um registro (possivelmente em mais de uma tabela) pode referenciar esse registro. Adicionando um novo registro de endereço poderia deixar o antigo recorde órfão se nenhuma outra linha tem uma relação de chave estrangeira a ele.

Eu tenho pensado sobre as seguintes maneiras de lidar com isso:

• Adicionar um novo registro de detalhe, e check-in um disparador de atualização da tabela mestre se o antigo recorde detalhe tem de ser eliminado. Isso exigiria conhecimento sobre todas as tabelas que têm relações para a tabela de detalhe, em todos eles ou em um sproc. Eu não gosto dessa perda de separação. Ele também envolveria mais tabelas na transação ativa.

• Deixe a tentativa gatilho para excluir o registro de detalhes de idade, e detectar quaisquer erros. Isso só se sente mal.

• Em directo com o registro órfão, e têm uma tarefa de manutenção periódica limpar todas as tabelas de detalhes.

O que é a forma preferida de alterações de dados punho em tabelas de detalhes que estão ligados a várias tabelas mestre? Alguma dica para ler sobre isso?

Answer 1

Parte do problema pode ser o design esquema original: as chaves estrangeiras apontam o caminho errado, o tratamento de endereços, números de telefone, etc., mestre em vez de detalhes. Isso pode ser conveniente quando você quer todos os usos de um determinado endereço para atualização de uma vez, mas na minha experiência, sempre se transforma em muitos casos excepcionais difíceis, por exemplo, uma pessoa de cada localização movimentos para que você precisa para quebrar seu vínculo vs todo um doméstico ou escritório movendo para que você atualizar o registro existente. Se você tentar esconder esse detalhe do usuário na tela de CRUD, você vai acabar com uma situação em que ele simplesmente não fazer o que quiser.

Se for feito dessa forma apenas para recolher valores duplicados, é efetivamente uma desnormalização do banco de dados: a mera existência da linha endereço é sem sentido. A única diferença é que ao contrário da maioria denormalizations, ele tenta ganhar eficiência espaço em vez de velocidade. Criando uma tabela de ligação a esse ponto é simplesmente agravando o problema.

Se você quiser, por exemplo, vários endereços por contato, fazer os endereços de uma tabela de detalhes com uma chave estrangeira apontando para voltar ao contato com os pais, e não se preocupe com valores de endereço duplicados porque Eles são valores apenas . Caso contrário, faça Endereço uma entidade real:. Adicionar um título ou campo de descrição e uma tela de CRUD para que ele possa ficar em sua própria como uma entidade

Answer 2

Em directo com o registro órfão, e têm uma tarefa de manutenção periódica limpar todas as tabelas de detalhes.

Answer 3

Eu acho que você estão a esbater os casos de exclusão e atualização.

Se você tem o cliente a cliente e b, e ambos usam o mesmo endereço, que seria refletida por registros em uma tabela relacional (ClientAddresses digamos, embora se você estiver armazenando endereços para várias entidades, tenho a certeza que será mais complexa do que isso)

Gostaria de pensar que, se dois clientes compartilhar e endereço de e é incorreta para o cliente um seria incorreto para o cliente b bem (ou seja, erros de entrada de dados), mas se você tem certeza que você não quer cliente de alterações ao a feita às informações endereço de base, remova o registro de associação (excluir ClientAddresses) e adicionar um novo endereço. Quando você executa a exclusão da tabela relacional (presumivelmente de um procedimento armazenado) verificar para ver se existem outros registros referentes ao registro de endereço a ser desassociada, se não eliminar da tabela base.