Roberto Concordo com você. A solução mais natural seria ter a chave estrangeira na própria tabela A.
[ ] André Em 15/05/07, Roberto <[EMAIL PROTECTED]> escreveu: > > Caros amigos > Tenho que tomar uma decisão de modelagem que envolve um autorelacionamento > e > gostaria de ajuda. > Tomem por exemplo uma tabela A. Nela um registro pode surgir em > decorrência > de um anteiror, na verdade um ou mais. > Assim a tabela poderia ficar da seguinte forma: > > TABELA_A > > Num_proc, origem, dpto, valor > > 1, null, DPTO1, 2040 > > 2, null, DPTO1, 3000 > > 3, null, DPTO1, 1000 > > 4, 2, DPTO2, 1500 > > 5, 2, DPTO4, 1500 > > 6, null, DPTO1, 1000 > > 7, 3, DPTO5, 1000 > > 8, 7, DPTO9, 1000 > > Como vocês podem ver, os processos 4 e 5 surgiram a partir do resultado do > 2, o processo 7 surgiu a partir do 3 e o 8 a partir do 7 > > Quero ver isso graficamente, tal como aquela janela lateral do explorer > que > mostra a hierarquia das pastas. Ficaria mais ou menos assim: > > 1 > 2-------+ > 4 > 5 > 3-------+ > 7-------+ > 8 > > Acho que posso deixar o campo origem na própria tabela A. E só com selects > poderia chegar aos pais e filhos sem problema. > Já um colega acha que seria melhor criar uma tabela, que seria uma > entidade > de relacionamento de A com A, com a seguinte estrutura: > > TABELA_A > > Num_proc, dpto, valor > > 1, DPTO1, 2040 > > 2, DPTO1, 3000 > > 3, DPTO1, 1000 > > 4, DPTO2, 1500 > > 5, DPTO4, 1500 > > 6, DPTO1, 1000 > > 7, DPTO5, 1000 > > 8, DPTO9, 1000 > > TABELA_B > > Num_proc, origem > > 4, 2 > > 5, 2 > > 7, 3 > > 8, 7 > > O que vocês acham? > O sistema sera em Java/Struts/JPA e o banco é o 8i > > Agradeço desde já a atenção de vocês > > Roberto > > > [As partes desta mensagem que não continham texto foram removidas]
