Discussion :

[AlexC3301]

bonjour,

je viens d'arriver dans une nouvelle boite (en plein milieu d'un projet en plus...), ou ils utilisent postgreSQL.

Ils utilisent souvent dans la base l'héritage:

• parent A
  
  • enfant B (trois champs supplementaires)
    • sous-enfant E
    • sous-enfant F
  • enfant C (trois champs supplémentaires)
    • sous-enfant G
    • sous-enfant H
  • enfant D (quatres champs supplémentaire)
    • sous-enfant I
    • sous-enfant J

les seules tables qui sont remplies sont les sous-enfants.

Je ne comprends pas pourquoi ils se sont embêtés à créer des tables intermédiaires, quand il aurait été plus éfficace (à mon humble avis) de créer une ou deux autres tables parent et faire un héritage multiple.

Je sais aussi que lorsqu'on fait un select sur le parent, on obtient les enregistrement des enfants (moins les champs ajoutés...), mais quel est l'avantage de se servir de ça par rapport au bon vieux modèle relationnel et ses requêtes avec jointure(s) ?

J'ai l'air vieux jeu (voire réac...), mais je ne vois pas l'avantage de cette méthode de conception. Quelqu'un pourrait-il m'éclairer?

Merci

[gleu_]

Il faudrait connaître mieux le schéma pour pouvoir te réponde. En fait, l'héritage et les jointures n'ont rien à voir. Le multiple héritage me paraît un peu suspect mais ton post manque d'infos pour émettre un avis plus affirmatif.

[GrandFather]

bonjour,

Je sais aussi que lorsqu'on fait un select sur le parent, on obtient les enregistrement des enfants (moins les champs ajoutés...), mais quel est l'avantage de se servir de ça par rapport au bon vieux modèle relationnel et ses requêtes avec jointure(s) ?

Ben justement de se passer des jointures. Et puis ça donne un vernis OO au relationnel qui doit rassurer bon nombre de développeurs peu à l'aise avec...

Le souci est que l'implémentation de l'héritage est incomplète dans PostgreSQL, il manque notamment l'héritage de contraintes telles que les clés étrangères et les clés primaires ; cela complique pas mal les choses, et il vaut mieux savoir exactement ce que l'on fait lorsqu'on décide d'utiliser l'héritage.

[AlexC3301]

Ben justement de se passer des jointures. Et puis ça donne un vernis OO au relationnel qui doit rassurer bon nombre de développeurs peu à l'aise avec...

Ok... Donc moi qui pensait que ça avait quelque chose à voir avec l'implémentation physique de la base sur le disque (style tous les inserts se font sur la table mère, et elle gère le pointage vers un espace ou sera contenu les champs supplémentaires si besoin de la table enfant), je suis dans le champs la?

Le souci est que l'implémentation de l'héritage est incomplète dans PostgreSQL, il manque notamment l'héritage de contraintes telles que les clés étrangères et les clés primaires ; cela complique pas mal les choses, et il vaut mieux savoir exactement ce que l'on fait lorsqu'on décide d'utiliser l'héritage.

Pour moi, ça ne semble apporter que des désavantages (problème de gestion de contraintes, obligation de faire une jointure quand même lorsqu'on interroge la table parent et qu'on veut savoir de quelle table vient le champs résultat, etc), si on exclus le coté rassurant pour les programmeurs juste habitué OO

Il doit bien y avoir un vrai avantage (j'entends pas la autre que d'éviter les jointures... ) à ça, non?

En passant, ou pourrais-je trouver une explication de la mécanique interne de l'héritage? Il y a des ouvrages qui traitent de ça? Une recherche sur google ne m'a donné que des résumés de l'exemple de la doc de postgre.

Merci pour votre aide

[GrandFather]

Il doit bien y avoir un vrai avantage (j'entends pas la autre que d'éviter les jointures... ) à ça, non?

Pour reprendre ton exemple, l'insertion d'un enregistrement dans la table "Sous-enfant E" qui comprend également les champs des tables ancêtres ne nécessite qu'un unique INSERT, là où il en faudrait 3 compris dans une transaction dans un schéma relationnel "classique", chacun déclenchant en plus le trigger lié à la contrainte de clé étrangère (obligatoire pour assurer sa cohérence à la base).

En passant, ou pourrais-je trouver une explication de la mécanique interne de l'héritage? Il y a des ouvrages qui traitent de ça? Une recherche sur google ne m'a donné que des résumés de l'exemple de la doc de postgre.

Personnellement je n'en connais pas, et je doute qu'il en existe, sauf peut-être des publications universitaires. Pour connaître les mécanismes sous-jacents dans PostgreSQL, il faut se reporter au code source ou s'inscrire à la liste de diffusion des développeurs.

[AlexC3301]

Merci GrandFather, c'est plus clair maintenant