Bonjour,
 
Je suis en train de faire un MCD relativement vaste où il y aura plusieurs héritages.
 
J'aimerais que ces héritages ne soient pas trop lourd de conséquence sur la programmation du code plus tard.
 
J'ai essayé de me renseigner sur le net, mais je ne trouve pas beaucoup de réponse, certains semble dire qu'il n'y a pas d'héritage en MySQL (qu'il faut une base PostgreSQL), certains semble contourner le problème en ne faisant qu'une table qui regroupe tous les champs des table mère et fille (beaucoup de champs vide dans ce cas, est-ce génant ?).
 
La base de donnée va être assez grosse, contenant des dizaines de milliers d'entregistrements (pour ces tables héritées) et des millions dans d'autres tables.
 
Qu'en est-il vraiment ?

Pour modéliser de l'héritage dans ta bdd il y a des solutions très simples - par exemple mettre l'id de la "table mère" dans la "table fille" en clé étrangère non nulle...mais la notion d'héritage n'existe pas directement.

Les bases "objet" gèrent l'héritage. PostGreSQL supporte ce mode.
 
Cependant, je trouve ça passablement pourri, c'est un moyen goret selon moi de dénormaliser une base, et gérer salement des données hétérogènes.
 
Il vaut mieux avoir une table "de base" (qui contient les éléments de base de ton objet) et des tables filles contenant les éléments "étendus" de ton objet.
 
Exemple :
 
Type de base : TIERS (Nom, Prenom)
Type étendu1 : CONTACT (Nom, Prenom, Email)
Type étendu2 : FOURNISSEUR (Nom, Prenom, Email, Adresse, RIB)
 
Tu as donc 3 tables TIERS (ID, Nom, Prenom) ; CONTACT (TIERS_ID, Email) ; FOURNISSEUR (TIERS_ID, Adresse, RIB).
 
TIERS_ID étant des FK vers TIERS.ID.
 
Ainsi, tu retrouves par exemple un CONTACT de la façon suivante :
 

SELECT TIERS.Nom, TIERS.Prenom, CONTACT.Email
FROM TIERS
INNER JOIN CONTACT ON CONTACT.TIERS_ID = TIERS.ID

 
Pas besoin donc de gestion "objet". Je ne me suis jamais vraiment penché sur les bases objet, mais honnêtement, je n'en vois pas l'intérêt mise à part transformer en usine à gaz quelquechose de simple.
 
Ensuite, rien ne t'empêche de dénormaliser ta base selon les besoins, en virant par exemple la table "CONTACT", estimant que 95% de tes TIERS sont des contacts, et que donc le champ EMAIL peut être rappatrié dans la table TIERS moyennant quelques lignes à NULL.

Ensuite, je ne vais pas m'attarder sur le sujet (j'en ai déjà parlé plein de fois), mais il y a la notion de "descripteurs" qui permet sans problème de créer virtuellemet une infinité de champs supplémentaires dans une table, avec une structure très simple, tout en permettant la segmentation par "type", ainsi que les contrôles de cohérences, etc.

Veuillez excuser cette exhumation de topic, mais je me pose la meme question quant au choix du SGBD (MySQL ou PostGreSQL), ou des notions d'heritage m'interesseraient beaucoup.
 

 
Cela m'a tout l'air de l'avis d'un vieux grincheux qui flatte ses vieux outils et insulte la jeunesse.
Qu'est-ce qui te permet d'affirmer que c'est une solution sale ?
Arrete-moi si je me trompe, mais j'imagine qu'en interne, PostgreSQL fait lui-meme la traduction avec plusieurs bases.
Il propose juste une couche d'abstraction supplementaire pour ne pas s'emmerder avec des jointures.
 
Merci pour vos conseils  

Une DB ce n'est pas une application orientée objet.
L'heritage a ca place dans une appli, pas dans une DB.
 
Ce n'est donc pas une reaction de vieux grincheux mais de quelqu'un qui a de l'experience et qui sait comment ne pas aller droit dans le mur.
 
Tu peux facilement faire ce que tu veux en utilisant plusieurs tables et des vues, sans exagerer avec les vues de vues.

Merci pour ta réponse.
Je comprends que l'héritage n'a pas sa place dans un SGBD, mais pourquoi en vouloir à un SGBD qui en fait un peu plus ?
Au niveau fonctionnel, performance, maintenance, etc , est-ce si mal que ca de l'utiliser, au delà des questions de principe de "pureté" ?

Je suis plutôt d'accord avec Oliii et la solution proposée par Magicbuzz : C'est comme ça que j'aurais fait aussi... Je vois pas trop l'intérêt de l'héritage dans une BD

Le probleme est le meme qu'avec toutes les couches d'abstraction, si c'est utilisé raisonablement ca ne pose pas de probleme, mais quand on l'utilise serieusement on a un risque d'avoir des gros problemes de perfs parceque ca n'a pas ete prevu pour ca.
 
Le grand classique pour les probleme de perf dans une DB c'est que ca fonctionne bien au debut, puis la taille augmente pcq l'appli s'etoffe ou que les clients sont plus gros et puis du jour au lendemain plus rien ne fonctionne et c'est un cauchemard a resoudre.
 
C'est plus facil de faire un design correct de DB quand on a le minimum d'abstraction, car c'est tres tres rare que les couches d'abstraction fasse le travail correctement (c'est normal vu que ca doit rester generic).

Il n'est jamais bon de s'appuyer sur une fonctionnalité "Spéciale" d'un SGBD.
Il vaut mieux rester le plus standard possible du point de vue SQL.
Ainsi, il sera possible de changer de SGBD assez facilement plus tard.
 

D'accord, merci pour vos conseils