Quote:
Non je ne vois pas de double emploi. Je suis de l'avis de jrebillat.
Double emploi n'est pas le terme. Et l'avis de jrebillat n'est pas nécessairement bon non plus. Il peut l'être ou pas selon ce qu'il est vraiment question de faire, ce qui n'est pas excessivement clair.
La difficulté, ce que dbobby appelle un casse-tête :lol:, c'est qu'il s'agit d'avoir une base de données arborescentes ce qui est effectivement très difficile.
Ce qui n'est pas clair dans la question, c'est comment traiter les données. Tout SQL ? Partie SQL partie code ? (en quel langage au fait ?) Dbobby parle de fichiers et en même temps d'Access ce que je trouve curieux.
Pour ce qui est de savoir si Access convient. Si on fait du tout SQL c'est non. Dans ce cas il faut éviter les jouets et prendre un SGDBR qui supporte les procédures stockées récursives. Les procédures en question travaillant sur des tables en auto-jointures
Si on fait du tout SQL, il faut savoir qu'au délà d'une profondeur de 5 le coût en terme de performances devient prohibitif avec des données organisées "id de parent dans l'enregistrement de l'enfant, etc". Si le volume de données et la profondeur sont importants, il faut gérer ce qu'on appelle une arborescence à représentation intervallaire. Avec ça les requêtes restent rapides, mais il y d'autre inconvénients, comme par exemple poser une limiter arbitraire au nombre de descendants d'une personne.
Ce qui n'est pas clair non plus est comment seront parcourues les données, toujours dans le même sens ? Dans la question j'ai cru comprendre que non
Quote:
les couples et leurs enfants respectifs, et aussi les ascendants des enfants.
Si c'est toujours dans le même sens, en remontant vers les ascendants, alors la suggestion de jrebillat fonctionne.
Si c'est dans les deux sens il y a problème car alors on a des graphes dont les noeuds ont plusieurs parents, ce qui n'a rien de pratique pour un parcours du graphe dans le sens descendant :lol:
Quote:
Les enfants n'ont pas à être copiés d'une table à l'autre, tu n'as pas besoin de faire un table enfants et une table parents, ca n'a pas de sens.
Non seulement ça n'a pas de sens, mais une redondance de données est toujours à proscrire comme le veut le bon sens. C'est même pour cette raison que l'on a inventée la clé étrangère ;) :D
Maintenant ce qui est peut être à proscrire c'est le concept de table pour faire cela. Du moins pour traiter les données sinon les stocker. Ce que je veux dire c'est que dans le cas des données arborencentes comme ça, (si grande profondeur et gros volume, je le répète) le SGDBR ne suffit pas à lui seul, il faut écrire du code autour...
Double emploi n'est pas le terme. Et l'avis de jrebillat n'est pas nécessairement bon non plus. Il peut l'être ou pas selon ce qu'il est vraiment question de faire, ce qui n'est pas excessivement clair.
La difficulté, ce que dbobby appelle un casse-tête :lol:, c'est qu'il s'agit d'avoir une base de données arborescentes ce qui est effectivement très difficile.
Ce qui n'est pas clair dans la question, c'est comment traiter les données. Tout SQL ? Partie SQL partie code ? (en quel langage au fait ?) Dbobby parle de fichiers et en même temps d'Access ce que je trouve curieux.
Pour ce qui est de savoir si Access convient. Si on fait du tout SQL c'est non. Dans ce cas il faut éviter les jouets et prendre un SGDBR qui supporte les procédures stockées récursives. Les procédures en question travaillant sur des tables en auto-jointures
Si on fait du tout SQL, il faut savoir qu'au délà d'une profondeur de 5 le coût en terme de performances devient prohibitif avec des données organisées "id de parent dans l'enregistrement de l'enfant, etc". Si le volume de données et la profondeur sont importants, il faut gérer ce qu'on appelle une arborescence à représentation intervallaire. Avec ça les requêtes restent rapides, mais il y d'autre inconvénients, comme par exemple poser une limiter arbitraire au nombre de descendants d'une personne.
Ce qui n'est pas clair non plus est comment seront parcourues les données, toujours dans le même sens ? Dans la question j'ai cru comprendre que non
Si c'est toujours dans le même sens, en remontant vers les ascendants, alors la suggestion de jrebillat fonctionne.
Si c'est dans les deux sens il y a problème car alors on a des graphes dont les noeuds ont plusieurs parents, ce qui n'a rien de pratique pour un parcours du graphe dans le sens descendant :lol:
Non seulement ça n'a pas de sens, mais une redondance de données est toujours à proscrire comme le veut le bon sens. C'est même pour cette raison que l'on a inventée la clé étrangère ;) :D
Maintenant ce qui est peut être à proscrire c'est le concept de table pour faire cela. Du moins pour traiter les données sinon les stocker. Ce que je veux dire c'est que dans le cas des données arborencentes comme ça, (si grande profondeur et gros volume, je le répète) le SGDBR ne suffit pas à lui seul, il faut écrire du code autour...