Pergunta

Como seria um estruturar uma mesa para uma entidade que pode ter uma relação um para muitos para si? Especificamente, eu estou trabalhando em um aplicativo para monitorar a criação de animais. Cada animal tem um ID; ele também tem um ID pai e um ID Dame. Portanto, é possível ter um um para muitos do senhor ou senhora à sua prole. Eu estaria inclinado a algo como isto: 

ID INT NOT NULL PRIMARY KEY
SIRE_ID INT 
DAME_ID INT

e registrar um valor nulo para os animais que foram comprados e adicionados ao plantel e um ID na tabela para o resto.

Assim:

  1. Pode alguém me aponte para um artigo página / web que discute modelar esse tipo de relacionamento?
  2. Se o ID ser um INT ou algum tipo de corda? A NULL no INT faria indicam que o animal não tem pais no banco de dados, mas uma String com valores de bandeira especiais poderia ser usado para indicar a mesma coisa.

  3. Será que isso possivelmente ser melhor modelados através de duas tabelas? Quero dizer uma tabela para os animais e um separada mesa indicando apenas parentesco e. g:.

    Animal

    ID INT NOT NULL PRIMARY KEY

    O parentesco

    ID INT NOT NULL PRIMARY KEY FOREIGN KEY

    SIRE_ID INT PRIMARY KEY FOREIGN KEY

    DAME_ID INT PRIMARY KEY FOREIGN KEY

Peço desculpas pela acima: o meu SQL está enferrujado. Espero que tipo de transmite o que eu estou pensando.

Foi útil?

Solução

Bem, este é um "normal" um-para-muitos e o método que sugiro é o clássico para resolvê-lo.

Note que duas tabelas são desnormalizada (eu não posso apontar exatamente onde o superkey-não-é-bem-deve-ser-subconjunto-de-outra-key-fsck-I-esqueceu parte é, mas eu' m certeza que ele está lá em algum lugar); a razão intuitiva é que uma tupla nos primeiros um jogos no máximo uma tupla no segundo, a menos que você tem lotes de animais com pai nula e dame IDs, não é uma boa solução em qualquer perspectiva (que piora o desempenho - necessidade uma junção -. e não reduz os requisitos de armazenamento)

Outras dicas

Eu acho que seu layout usando apenas uma tabela é bom. Você definitivamente quero manter SIRE_ID e DAME_ID no mesmo tipo de dados como ID. Você também quer declará-los como chaves estrangeiras (é possível ter uma volta ponto chave estrangeira para o mesmo mesa, e uma chave estrangeira também pode ser nulo). 

ID INT NOT NULL PRIMARY KEY
SIRE_ID INT REFERENCES TABLENAME (ID)
DAME_ID INT REFERENCES TABLENAME (ID)

Usando este layout, você pode facilmente procurar os animais progenitores, e você também pode construir uma árvore de prole para um determinado animal (para Oracle há CONNECT BY)

Eu fiz uma pergunta semelhante um número de meses atrás, no site do MySQL. Eu recomendaria que você dê uma olhada na resposta que recebi de Peter Brawley em relação a este tipo de relação: http :? //forums.mysql.com/read.php 135,187196,187196 # msg-187196

Se você quiser pesquisar ainda mais o assunto, então eu recomendo que você olhar para hierarquias da árvore na Wikipedia.

Uma alternativa sugerida arquitetura (que seria totalmente normalizado) seria algo parecido com o seguinte:

Table: animal

ID | nome | Raça

Table: pedigree

animal_id | parent_id | ParentType (seja pai ou dama)

INT é a melhor escolha para a coluna ID e mais adequado se você deve usar uma seqüência para gerar os IDs exclusivos.

Eu não vejo nenhum benefício em divisão do projeto em duas tabelas.

Eu não sei sobre criação de animais, mas parece que seu Sire_ID é o pai e Dame_ID é a mãe? Sem problemas. Uma linha por animal, sire_ nula e dame_ID é para animais comprados, eu não forsee quaisquer problemas. 

[ID],[Sire_ID],[Dame_ID];
0,null,null  (male)
1,null,null  (female)
2,null,null  (female)
3,0,1 (male)
4,0,2 (male)
5,null,null  (female)
6,3,5
7,4,5

e assim por diante. Você provavelmente preencher um TreeView ou XmlNodeList em um loop while ... 

While (myAnimal.HasChildren) {
 Animal[] children = GetChildren(Animal.ID)
 for (int x=0; x<children.length; x++) 
  myAnimal.Children.Add(children[x]);
}

Neste caso, Animal.Children é uma coleção de animais. Portanto, myAnimal.Children [0] .Father voltaria myAnimal. .Parent [] poderia ser uma coleção de seus dois pais, que deve funcionar, desde que [0] é sempre um dos pais (pai) e [1] é sempre o outro (mãe).

Faça ID um PK Autonumber e atribuir Sire_ID e Dame_ID programaticamente, retornando os IDs de seus pais. Não há relações de chave estrangeira deve ser neccessary embora ambos os IDs mãe possam referenciar de volta para ID se você realmente quer.

Use o "conectar" cláusula com SQL para dizer-lhe que a hierarquia a seguir.

Não é realmente uma relação um para muitos, a menos que um animal pode ter muitos pais.

Eu deixá-lo como uma única tabela com a identificação única chave para o animal, um campo int para cada um dos pais, e provavelmente um campo de texto para uso para notas gerais sobre o animal, como onde foi comprado, se é isso o caso.

Eu acho que desde que é claro que um animal só tem um pai e uma barragem, que o uso de uma única tabela faria mais sentido. Minha preferência é usar int ou bigint como o identificador de linha, com um valor nulo, significando nenhuma relação. Eu provavelmente iria, então, para usar algum outro método para identificar exclusivamente os animais para que eles não acabam na mesa duas vezes e criar um índice exclusivo nessa coluna também.

Parece que você quer construir algo como uma árvore.

Que tal algo como:? 

 ID          Primary Key,
 Parent_ID   Foreing_Key
 ( data )

Existem algumas funcionalidades para fazer querys em tabelas com relações com eles mesmos. Veja a sintaxe de Conectar por : http: // www.adp-gmbh.ch/ora/sql/connect_by.html

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top