Arquivo Discussoes de Programacao e Tecnologia 
O problema é simples:
Tenho uma árvore de uma entidade. Ela possui uma autorreferência para indicar quem seria o seu pai.
Por comodidade, em vez de colocarem uma referência da entidade, colocaram o id de banco referente ao pai.
Vocês consideram isso um anti pattern? Queria a opinião de vocês.
O problema é simples:Tenho uma árvore de uma entidade. Ela possui uma autorreferência para indicar quem seria o seu pai.
Por comodidade, em vez de colocarem uma referência da entidade, colocaram o id de banco referente ao pai.Vocês consideram isso um anti pattern? Queria a opinião de vocês.
dexa eu ver se eu entendi direito, você tem uma tabela X, que tem uma coluna id (por exemplo) que é a pk e um idPai que seria uma FK apontando para a pk da mesma tabela?
se for isso, eu acredito que essa seja a forma correto de você montar uma árvore, inclusive tenho mais de um caso assim em um sistema que trabalho hoje.
O problema é simples:Tenho uma árvore de uma entidade. Ela possui uma autorreferência para indicar quem seria o seu pai.
Por comodidade, em vez de colocarem uma referência da entidade, colocaram o id de banco referente ao pai.Vocês consideram isso um anti pattern? Queria a opinião de vocês.
Então, isso era o que eu pensava…
Um dos motivos d eu achar ruim é que essa referência depende de uma informação que foi criada no banco.
Agora, suponha que eu queira fazer um teste para comparar 2 árvores. Não gostaria de ter que depender do banco, logo eu crio ids artificiais.
Imagine que uma árvore contem mais controles que o outro. Não posso simplesmente comparar os pais pelo id. Eu sempre vou precisar da árvore para saber quem é o pai de cada entidade. E pior, precisaria das 2 árvores.
Mas uma coisa que eu não cheguei a pensar é como ficaria a comparação se eu quiser incluir a verificação do pai no equals(), provavelmente seria algo recursivo.
Se eu tivesse a referência do objeto pai (e não um id), isso seria possível. Se não, vou precisar de um “contexto” para conseguir comparar…
Então, isso era o que eu pensava…Um dos motivos d eu achar ruim é que essa referência depende de uma informação que foi criada no banco.
Agora, suponha que eu queira fazer um teste para comparar 2 árvores. Não gostaria de ter que depender do banco, logo eu crio ids artificiais.
Imagine que uma árvore contem mais controles que o outro. Não posso simplesmente comparar os pais pelo id. Eu sempre vou precisar da árvore para saber quem é o pai de cada entidade. E pior, precisaria das 2 árvores.Mas uma coisa que eu não cheguei a pensar é como ficaria a comparação se eu quiser incluir a verificação do pai no equals(), provavelmente seria algo recursivo.
Se eu tivesse a referência do objeto pai (e não um id), isso seria possível. Se não, vou precisar de um “contexto” para conseguir comparar…
não é uma coisa sim simples com certeza, mas sim, com certeza é recursivo.
quanto a comparação de uma árvore com outra, eu imagino que você precisaria das duas árvores de qualquer forma, sim, para trabalhar com isso muito provavelmente você vai precisar de algo recursivo. No oracle você tem o connect by prior para montar a árvore por exemplo se você usar o hibernate da para ele te ajudar nesse sentido. Você tendo o idPai referenciando a propria tabela (com fk mesmo), vocÊ pode ter um objeto de si mesmo como pai e um List<“siProprio”> filhos, se você deixar esse filhos como EAGER o loading dele vai ser trazido de forma automatica, o equals poderia considerar o equals dos filhos, ou dos pais… a maior complexidade me parece ser em como se deve comparar uma árvore (qaul é a regra lógica) do que de linguagem mesmo…