Le livre de Craig Larman "Applying UML with Patterns" décrit les 3 solutions courantes à ce problème.
Vos exemples ne sont pas particulièrement utiles - il n'y a aucune raison logique d'avoir 3 façons différentes de gérer le nom d'une personne dans votre base de données (bien que cela se produise régulièrement en raison de l'étrangeté de l'importation/exportation de données).
Cependant, il est très courant qu'il y ait une entité "personne" qui peut être un employé (avec employee_id), un contact (avec un lien vers la table des prospects) ou un client (avec un customer_id et un lien vers la table des commandes) .
Dans le livre de Larman, il donne 3 solutions.
Une table pour les gouverner tous Ici, vous créez une seule table avec toutes les colonnes connues. Cela crée une table désordonnée et pousse la responsabilité de connaître les règles de persistance de chaque sous-classe à la couche d'application - la base de données n'imposera pas la nécessité pour les clients d'avoir un customer_id. Cependant, cela rend les jointures beaucoup plus faciles - toute table qui doit être liée à une personne peut simplement, eh bien, être liée à la table person.
Tableau des superclasses Cela nettoie les choses en extrayant les attributs communs dans une seule table - par ex. "person" - et pousse les champs spécifiques à la sous-classe vers les tables de sous-classe. Ainsi, vous pouvez avoir "personne" comme table de superclasse et des tables "contact", "employé" et "client" avec les données de sous-classe spécifiques. Les tables de sous-classe ont une colonne "person_id" pour renvoyer à la table de superclasse. C'est plus complexe - cela nécessite généralement une jointure supplémentaire lors de la récupération des données - mais aussi beaucoup moins sujet aux erreurs - vous ne pouvez pas corrompre accidentellement le modèle de données avec un bogue qui écrit des attributs invalides pour "employé".
Table par sous-classe - C'est ce que vous avez décrit. Cela introduit une bonne quantité de duplication dans le modèle de données, et vous avez souvent des jointures conditionnelles - "joindre sur la table x si type de personne =y", ce qui peut compliquer le code d'accès aux données.
