Comment concevoir une table de produits pour plusieurs produits où chaque produit a de nombreux paramètres

Question

Je n'ai pas beaucoup d'expérience en conception de tables. Mon objectif est de créer une ou plusieurs tables de produits répondant aux exigences suivantes : prendre en charge plusieurs types de produits (TV, mobile, ordinateur, ...). Chaque type de produit a un ensemble de paramètres différent, par exemple : le téléphone aura la couleur, la taille, le poids, le système d'exploitation, etc. Un ordinateur aura un processeur, un disque dur, de la mémoire, etc. Les jeux de paramètres doivent être dynamiques. Vous pouvez ajouter ou modifier n'importe quel paramètre. Comment puis-je répondre à ces exigences sans créer un tableau distinct pour chaque type de produit ?

P粉930448030 · Answer

@StoneHeart

J'utiliserai toujours EAV et MVC.

@Bill Karvin

Toutes les choses que vous avez mentionnées ici :

Vérification des données
Vérification orthographique du nom d'attribut
Colonnes/champs obligatoires
Gérer la destruction des propriétés dépendantes

À mon avis, aucun de ces éléments ne devrait être dans une base de données, car aucune base de données ne peut gérer ces interactions et exigences à un niveau approprié que le langage de programmation de l'application.

À mon avis, utiliser une base de données de cette manière, c'est comme enfoncer un clou avec une pierre. Vous pouvez le faire avec une pierre, mais ne devriez-vous pas utiliser un marteau plus précis spécialement conçu pour cette activité ?

Ce problème peut être résolu en effectuant quelques requêtes sur une partie des données et en les traitant sous forme de tableau. Même si vous disposez de 600 Go de données produit, si vous avez besoin d'obtenir des données pour chaque ligne de ce tableau, vous pouvez les traiter par lots.

De plus, si vous souhaitez améliorer les performances de vos requêtes, vous pouvez sélectionner certaines opérations, telles que le reporting ou la recherche de texte globale, et préparer des tables d'index pour stocker les données requises et les régénérer périodiquement, par exemple toutes les 30 minutes.

Vous n’avez même pas à vous soucier du coût du stockage de données supplémentaire, car cela devient de moins en moins cher chaque jour.

Si vous êtes toujours préoccupé par les performances des opérations effectuées par l'application, vous pouvez toujours utiliser le langage Erlang, C++, Go pour prétraiter les données, puis traiter davantage les données optimisées dans l'application principale.

P粉504920992 · Answer

Vous disposez d'au moins cinq options pour modéliser la hiérarchie de types que vous décrivez :

Héritage de table unique : utilisez une table pour tous les types de produits, avec suffisamment de colonnes pour stocker tous les attributs de tous les types. Cela signifie qu'il y a de nombreuses colonnes sur chaque ligne, dont la plupart sont NULL sur une ligne donnée.
Héritage de table de classe : utilisez une table pour les produits pour stocker les attributs communs de tous les types de produits. Ensuite, utilisez un tableau pour chaque type de produit afin de stocker les attributs spécifiques à ce type de produit.
Héritage de la table concrète : Il n'y a pas de table pour les attributs communs du produit. Utilisez plutôt une table pour chaque type de produit afin de stocker les attributs de produit courants et les attributs spécifiques au produit.
LOB sérialisé : utilisez une table pour les produits afin de stocker les attributs communs à tous les types de produits. Une colonne supplémentaire stocke un BLOB de données semi-structurées, qui peuvent être au format XML, YAML, JSON ou autres. Ce BLOB permet de stocker des attributs spécifiques à chaque type de produit. Vous pouvez utiliser des modèles de conception complexes pour décrire ce processus, tels que Facade et Memento. Mais quoi qu'il en soit, vous disposez d'un BLOB de propriété qui ne peut pas être facilement interrogé en SQL, vous devez récupérer l'intégralité du BLOB dans l'application et le trier là-bas.
Entité-Attribut-Valeur : utilisez un tableau pour les produits et un tableau qui fait pivoter les attributs en lignes au lieu de colonnes. L’EAV n’est pas une conception efficace dans le paradigme relationnel, mais de nombreuses personnes l’utilisent encore. Il s'agit du "modèle de propriété" mentionné dans une autre réponse. Consultez d'autres questions étiquetées eav sur StackOverflow pour en savoir plus sur certains pièges.

J'ai écrit davantage à ce sujet dans une démo intitulée Scalable Data Modeling.

Autres réflexions sur l'EAV : Même si beaucoup de gens semblent aimer l'EAV, ce n'est pas le cas de moi. Cela semble être la solution la plus flexible et donc la meilleure. Cependant, n'oubliez pas cette devise TANSTAAFL. Voici quelques inconvénients de l'EAV :

Impossible de rendre une colonne obligatoire (équivalent à NOT NULL).
Impossible de valider les entrées à l'aide des types de données SQL.
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 avec 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.

La flexibilité offerte par EAV nécessite des sacrifices dans d'autres domaines, ce qui rend potentiellement votre code aussi complexe (voire pire) que si vous résolviez le problème d'origine de manière plus traditionnelle.

Et, dans la plupart des cas, avoir ce niveau de flexibilité n’est pas nécessaire. Dans votre question sur les types de produits, il serait plus simple de créer une table pour chaque type de produit afin de stocker les attributs spécifiques au produit, afin que vous puissiez au moins appliquer une structure cohérente pour les entrées du même type de produit.

Je n'utiliserais EAV que si chaque ligne est autorisée à avoir un ensemble d'attributs différent. L’EAV est excessif lorsque vous disposez d’un ensemble limité de types 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 avec des fonctions JSON spéciales pour les prendre en charge, la requête devient trop complexe. Le stockage de documents JSON nécessite plus d'espace de stockage que leur stockage dans des lignes et des colonnes normales.

Fondamentalement, dans une base de données relationnelle, aucune de ces solutions n'est simple ou efficace. Le concept même de « propriétés mutables » est fondamentalement incompatible avec la théorie relationnelle.

En fin de compte, vous devez choisir l'une de ces solutions en fonction de la manière dont vous interrogez les données, en fonction de la solution la moins mauvaise pour votre application. Par conséquent, avant de choisir une conception de base de données, vous devez savoir comment interroger les données. Aucune solution n’est « la meilleure », car n’importe quelle solution peut constituer le meilleur choix pour une application.