Design de banco de dados SQL

Question

Estou fazendo um banco de dados para um programa em que devo modelar algumas relações na família.ex:X é pai para y, y é filho para x

Então, eu tenho um Membros tabela com todas as informações sobre cada membro, então pensei em fazer muitos a muitos relacionados entre o Membros mesa e si mesmo para que o Membro_member A mesa da ponte estará tendo as colunas "Fk_fromid, fk_toid" como chave composta (isso está correto?) E "Fk_relationtype" Como uma chave estrangeira para Types de relação Tabela que terá o tipo de relação "Pai, mãe, filho, filha" e duas relações como uma a muitas da mesa dos membros para essas duas chaves estrangeiras

Meu problema é : Ao excluir, se eu escolher em cascata, farei ciclos porque, se eu excluir um membro, haverá dois passes de exclusão para registros relacionados em Membro_member Bridge, sabendo que no programa sempre que inserir uma relação pai, inserirei uma relação de filho também na tabela membro_member, existe um caminho ou uma solução alternativa possível para permitir cascata para que, sempre que eu excluir um membro, excluirei os registros relacionados dentro Membro_member Independentemente de serem registrados em A a ou a de coluna de chave estrangeira

Então, eu não sei o que fazer, é um design correto em primeiro lugar ou o quê? , o que devo fazer sobre andar de bicicleta, também o que você acha que um design melhor para o mesmo problema deve saber que eu preciso especificar que tipo de relação entre as duas partes

Muito obrigado por qualquer ajuda e desculpe pelo mau bishoy inglês

Answer 1

O SQL não lida muito bem com problemas de "rede".

A tabela de pontes membros-membros é um nome terrível. É uma ponte "membro-parente" (ou "pai-filho"). As tabelas de ponte não devem ter uma "chave composta". As tabelas de ponte têm uma chave substituta (apenas um número seqüencial) e um par de referências de FK a outras tabelas. Os dois FKs devem ter nomes como "membro" e "pai" para deixar perfeitamente claro qual é o relacionamento nesta tabela.

Todo mundo tem um pai. Nem todo mundo tem filhos. Alguns pais não terão pais neste banco de dados; Eles são os "principais pais".

É mais fácil se os principais pais tiverem linhas na ponte pai-filho com um pai de nulo. Dessa forma, você evita os joins externos do super complexo-todo membro tem pelo menos uma linha de membros-parentes; Idealmente dois.

Você encontrará muitos problemas de "ciclismo", já que os relacionamentos são transitivos.

Observe que você não pode-em uma única consulta SQL padrão-encontre todos os membros da família ou todos os pais de volta ao topo da família, ou a todas as crianças e netos. Existem extensões SQL que tornam isso possível, mas o padrão não lida bem.

O exclusão em cascata não funciona bem porque os relacionamentos em uma família são direcionados de duas maneiras (pai para filhos, filho para pais), mas o SQL tem apenas um tipo de direção (referência da FK).

Você pode tentar garantir que todo membro deve ter pelo menos uma (e no máximo duas) linhas em "membro-parente" e A exclusão de um membro exclui as duas linhas em "membro-parente" e As chaves têm os nomes adequados, você pode fazer partes deste trabalho.

Observe que, quando você excluir um membro, isso quebrará os relacionamentos dos pais. Você exclui a linha de membro-parente. Isso é bom. E os filhos deles? As outras linhas que têm parente de membros que se referem a este pai excluído estão agora quebradas. O que isto significa? O que deveria ser feito?

Não há padrão responda. A remoção de linhas de um gráfico conectado deixa os elementos desconectados. Você tem que elaborar algumas regras sensatas para isso.

Como o SQL não faz isso bem, todos os designs parecem ter problemas.

Answer 2

1. Supondo que cada membro possa ter apenas uma mãe e um pai, você seria capaz de derivar todos os relacionamentos simplesmente mantendo um mother_id e father_id campo no members tabela.

   No entanto, isso só funcionaria se o seu banco de dados não vou ter informações ausentes. Por exemplo, se o membro X for o irmão do membro Y, não haveria como saber disso, a menos que os pais de X e Y sejam armazenados no banco de dados.

   Se o seu banco de dados não estiver tendo informações ausentes, o acima pode ser mais fácil gerenciar a integridade dos dados. As consultas podem ficar um pouco complexas no entanto.

2. o member_member Bridge que você sugeriu ter um problema sério, pois implica uma direção do relacionamento, de modo que, se X é o pai de Y, Y também é filho de X. Você sugeriu definir o relacionamento duas vezes em ambas as direções, mas em geral isso é não recomendado. Essa é uma forma de duplicação de dados e você pode lutar para aplicar a integridade referencial com a duplicação de dados. Lembre -se de que o DBMS não sabe que X é o pai de Y é o mesmo que Y é filho de X.

Estou ciente de que essa não é uma resposta completa, mas apenas algumas observações. Eu concordo totalmente com Resposta de S.Lott Como não há uma maneira padrão de "resolver" isso com bancos de dados relacionais.