Concevoir des tableaux de produits multifonctionnels avec plusieurs paramètres pour différents types de produits

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 :

• Prend en charge plusieurs produits (TV, téléphone portable, PC...). Chaque produit a un ensemble de paramètres différent, tels que :

  • Le téléphone aura la couleur, la taille, le poids, le système d'exploitation...

  • Le PC aura un processeur, un disque dur, de la RAM...

• Les jeux de paramètres doivent être dynamiques. Vous pouvez ajouter ou modifier tous les paramètres de votre choix.

Comment répondre à ces exigences sans formulaires séparés pour chaque produit ?

Answer 1

@StoneHeart

J'utiliserai toujours EAV et MVC pour arriver ici.

@billcavin

Toutes ces 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, cela n'a pas du tout sa place dans une base de données, car aucune base de données ne peut gérer ces interactions et ces besoins au niveau approprié comme 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 et conçu spécifiquement pour ce type d'activité ?

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

De plus, si vous souhaitez améliorer les performances de votre requête, vous pouvez sélectionner certaines opérations comme la création de rapports ou la recherche de texte globale et préparer une table d'index pour celle-ci qui stockera les données requises et sera régénérée périodiquement, disons toutes les 30 minutes une fois.

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 vous souciez toujours des performances des opérations effectuées par votre application, vous pouvez toujours utiliser les langages Erlang, C++, Go pour prétraiter les données puis traiter davantage les données optimisées dans l'application principale. p>

Answer 2

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.