human
Dites, une table ```car``` a une relation un-à-un avec les tables ```electric_car```, ```gas_car```, et ```hybrid_car```. Si une ```car``` est une ```electric_car```, elle ne peut plus apparaître dans ```gas_car``` ou ```hybrid_car```, etc. 
Est-ce une mauvaise pratique d'avoir plusieurs relations un-à-un mutuellement exclusives dans la conception d'une base de données
gpt
Les différents types de voitures sont une instance d'un problème général qui se pose encore et encore dans la modélisation des données. Cela s'appelle "généralisation/spécialisation" dans la modélisation ER et "superclasse/sous-classe" dans la modélisation objet.
Un modélisateur d'objets utilise les fonctionnalités d'héritage intégrées dans le modèle d'objet pour résoudre le problème assez facilement. Les sous-classes étendent simplement la superclasse.
Le modélisateur relationnel est confronté à un problème. Comment concevoir les tables de manière à émuler les avantages que l'on obtiendrait de l'héritage ?
La technique la plus simple s'appelle l'héritage de table unique. Les données sur tous les types de voitures sont regroupées dans une seule table pour les voitures. Il y a une colonne, car_type, qui regroupe toutes les voitures d'un seul type. Aucune voiture ne peut appartenir à plus d'un type. Si une colonne est sans importance pour, disons, les voitures électriques, elle sera laissée NULL dans les lignes qui concernent les voitures électriques.
Cette solution simple fonctionne bien pour les cas plus petits et plus simples. La présence de nombreux NULL ajoute un tout petit peu de surcharge de stockage et un peu de surcharge de récupération. Le développeur peut devoir apprendre la logique à trois valeurs de SQL si des tests booléens sont effectués sur des colonnes nulles. Cela peut être déconcertant au début, mais on s'y habitue.
Il existe une autre technique, appelée héritage de table de classe. Dans cette conception, il y a des tables séparées pour les voitures à essence, les voitures électriques et les voitures hybrides, en plus d'une table combinée, car, pour toutes ces voitures. Lorsque vous souhaitez obtenir toutes les données sur un type spécifique de voiture, vous joignez la table car à la table spécialisée appropriée. Il y a moins de NULL dans cette conception, mais vous effectuez plus de jointures. Cette technique fonctionne mieux dans les cas plus grands et plus complexes.
Il existe une troisième technique appelée clé primaire partagée. Cette technique est souvent utilisée en conjonction avec l'héritage de table de classe. Les tables spécialisées pour les sous-classes ont, comme clé primaire, une copie de la clé primaire de l'entrée correspondante dans la table car. Cette colonne id peut être déclarée à la fois clé primaire et clé étrangère.
Cela nécessite un peu de programmation supplémentaire lors de l'ajout de nouvelles voitures, mais cela rend les jointures simples, faciles et rapides.
Les superclasses et les sous-classes se produisent tout le temps dans le monde réel. N'ayez pas peur. Mais testez votre conception initiale pour la performance. Si votre première tentative est simple et solide, vous pourrez l'ajuster pour l'accélérer.