P粉5140018872023-10-19 13:03:38
Vous disposez d'au moins les cinq options suivantes pour modéliser la hiérarchie de types que vous décrivez :
Héritage de table unique : une table s'applique à tous les types de produits, avec suffisamment de colonnes pour stocker tous les attributs de tous les types. Cela signifie beaucoupcolonnes, dont la plupart sont NULL sur une ligne donnée.
Héritage de table de classes : une table de produits qui stocke les types d'attributs communs à tous les produits. Puis une table par type de produit, stockant les attributs spécifiques à ce type de produit.
Héritage de table en béton : table sans attributs communs du produit. Au lieu de cela, une table par type de produit stocke les attributs de produit courants et les attributs spécifiques au produit.
LOB sérialisé : une table de produits qui stocke les attributs communs à tous les types de produits. Une colonne supplémentaire stocke un BLOB de données semi-structurées au format XML, YAML, JSON ou autre format. Ce BLOB permet de stocker des attributs spécifiques à chaque type de produit. Vous pouvez utiliser des modèles de conception sophistiqués pour décrire cela, tels que Facade et Memento. Quoi qu'il en soit, vous ne pouvez pas facilement interroger un grand nombre de propriétés dans SQL ; vous devez extraire l'intégralité du blob vers l'application et l'y trier.
Entité-Attribut-Valeur : Un tableau de produits et un tableau qui fait pivoter les attributs en lignes au lieu de colonnes. L’EAV n’est pas une conception valide en ce qui concerne les paradigmes relationnels, mais de nombreuses personnes l’utilisent encore. Il s'agit du "modèle de propriété" mentionné dans une autre réponse. Voir les autres questions étiquetées eav sur StackOverflow pour connaître certains pièges.
J'ai écrit plus à ce sujet dans la présentation
Scalable Data Modeling.
Autres réflexions sur l'EAV : Même si beaucoup de gens semblent aimer l'EAV, ce n'est pas mon cas. Cela semble être la solution la plus flexible et donc la meilleure. Mais rappelez-vous cette devise
TANSTAAFL. Voici quelques-uns des inconvénients de l’EAV :
- Impossible de forcer la spécification de la colonne (équivalent à
NOT NULL).
- Impossible d'utiliser le type de données SQL pour valider les entrées.
- Impossible de garantir une orthographe cohérente des noms de propriété.
- Il n'est pas possible de placer une clé étrangère, telle qu'une table de recherche, sur la valeur d'une propriété donnée.
- Obtenir des résultats dans une disposition de tableau traditionnelle est complexe et coûteux car pour obtenir les attributs de plusieurs lignes, vous devez faire
JOIN pour chaque attribut.
Le niveau de flexibilité d'EAV vous oblige à faire des sacrifices dans d'autres domaines, ce qui peut rendre votre code plus complexe (ou pire) que la résolution du problème d'origine de manière plus traditionnelle.
Et dans la plupart des cas, il n’est pas nécessaire d’avoir ce niveau de flexibilité. Dans la question du PO sur les types de produits, il serait beaucoup plus simple de créer un tableau des attributs spécifiques au produit pour chaque type de produit, appliquant ainsi au moins une structure cohérente pour les entrées du même type de produit.
Je n'utiliserais EAV que s'il est nécessaire de permettre à chaque ligne d'avoir potentiellement un ensemble de propriétés différent. L’EAV est excessif lorsque vous disposez d’une gamme limitée de produits. L'héritage de table de classe serait mon premier choix.
Mise à jour 2019 : plus je vois des gens utiliser JSON comme solution au problème des « nombreuses propriétés personnalisées », moins j'aime cette solution. Même l'utilisation de fonctions JSON spéciales les prend en charge. Le stockage d'un document JSON nécessite plus d'espace de stockage que son stockage dans des lignes et des colonnes simples.
Fondamentalement, aucune de ces solutions n'est simple ou efficace dans les bases de données relationnelles. L'idée même d'avoir des « propriétés mutables » est fondamentalement incompatible avec la théorie relationnelle.
En fin de compte, vous devez choisir une solution qui a le moins d'impact sur votre application. Par conséquent, avant de choisir une conception de base de données, vous devez savoir comment interroger les données. Il n’existe aucun moyen de choisir une « meilleure » solution, car n’importe quelle solution peut être la meilleure pour une application donnée.
répondre
0