Table des produits, nombreux types de produits, chaque produit a plusieurs paramètres

Question

je suis n'ont pas beaucoup d'expérience dans la conception d'une table. Mon but est de faire une table de produit(s), il doit la conception de fixer des exigences ci-dessous:

• En charge de nombreux types de produits (TV, Téléphone, PC, ...). Chaque type de produit a une autre série de paramètres comme:

  • Téléphone aura la Couleur, la Taille, le Poids, les OS...

  • PC aura CPU, HDD, RAM...

• Jeu de paramètres doit être dynamique. Vous pouvez ajouter ou modifier n'importe quel paramètre vous le souhaitez.

Je ne veux pas faire un tableau pour chaque type de produit. J'ai donc besoin d'aide pour trouver une solution correcte.

Merci.

Answer 1

Vous avez au moins cinq options pour la modélisation de la hiérarchie du type que vous décrivez:

• Seul l'Héritage de Table: une table pour tous les types de Produits, avec assez de colonnes pour stocker tous les attributs de tous les types. Cela signifie beaucoup de colonnes, dont la plupart sont NULLES sur une ligne donnée.

• La classe de l'Héritage de Table: une table pour les Produits, le stockage des attributs communs à tous les types de produits. Puis une table par type de produit, le stockage des attributs spécifiques à ce type de produit.

• Le béton de l'Héritage de Table: pas de table pour le commun des caractéristiques des Produits. Au lieu de cela, un tableau pour chaque type de produit, le stockage commun attributs du produit, et le produit des attributs spécifiques.

• Sérialisé MÉTIER: Une table pour les Produits, le stockage des attributs communs à tous les types de produits. Une colonne supplémentaire magasins une GOUTTE de données semi-structurées en XML, YAML, JSON, ou tout autre format. Ce BLOB permet de stocker les attributs spécifiques à chaque type de produit. Vous pouvez utiliser la Conception de fantaisie Schémas de le décrire, comme la Façade et le Souvenir. Mais peu importe, vous avez une goutte d'attributs qui ne peuvent pas facilement être interrogés dans SQL; vous devez chercher de l'ensemble de blob revenir à l'application et à les trier.

• Entité-Attribut-Valeur: Une table pour les Produits, et une table qui pivote attributs de lignes, au lieu de colonnes. La VAE est pas valide à l'égard du paradigme relationnel, mais beaucoup de gens l'utiliser de toute façon. C'est la "Propriétés du Modèle" mentionné par une autre réponse. Voir les autres questions avec la vae tag sur StackOverflow pour certains pièges.

J'ai écrit plus à ce sujet dans une présentation, Extensible de Modélisation de Données.

---

Réflexions supplémentaires sur la VAE: Bien que beaucoup de gens semblent privilégier la VAE, je n'ai pas. Il semble que la solution la plus souple, et donc le meilleur. Cependant, gardez à l'esprit l'adage TANSTAAFL. Voici quelques-uns des inconvénients de VAE:

• Aucun moyen de faire une colonne obligatoire (l'équivalent de NOT NULL).
• Aucun moyen d'utiliser les types de données SQL pour valider les inscriptions.
• Aucun moyen de s'assurer que les noms d'attributs sont définis de manière cohérente.
• Pas moyen de mettre une clé étrangère sur les valeurs d'un attribut donné, par exemple pour une table de recherche.
• Récupérer des résultats dans un classique de tableaux de mise en page est complexe et coûteux, parce que pour obtenir les attributs de plusieurs lignes, vous devez faire JOIN pour chaque attribut.

Le degré de flexibilité EAV vous donne exige des sacrifices dans d'autres domaines, probablement rendre votre code aussi complexe (ou pire) qu'il aurait été à résoudre le problème de manière plus conventionnelle.

Et dans la plupart des cas, il est inutile d'avoir un degré de flexibilité. Dans le cas des OP question sur les types de produits, il est beaucoup plus simple de créer une table par type de produit pour le produit attributs spécifiques, si vous avez une structure cohérente appliquée, du moins pour les inscriptions du même type de produit.

J'aimerais utiliser la VAE seulement si chaque ligne doit être autorisé à potentiellement avoir un ensemble distinct de qualités. Lorsque vous avez un ensemble fini de types de produits, la VAE est exagéré. La classe de l'Héritage de Table serait mon premier choix.

Answer 2

@StoneHeart

Je voudrais aller ici avec EAV et MVC.

@Bill Karvin

Voici quelques-uns des inconvénients de VAE:

No way to make a column mandatory (equivalent of NOT NULL).
No way to use SQL data types to validate entries.
No way to ensure that attribute names are spelled consistently.
No way to put a foreign key on the values of any given attribute, e.g.

pour une table de recherche.

Toutes ces choses que vous avez mentionnées ici:

• la validation des données
• les noms des attributs de l'orthographe de validation
• obligatoire colonnes/champs
• la manipulation de la destruction des attributs dépendants

à mon avis, n'appartiennent pas dans la base de données à tous les car aucun des bases de données est capable de gérer ces interactions et des exigences relatives à un bon niveau comme le langage de programmation de l'application.

À mon avis, à l'aide de la base de données de cette façon, c'est comme utiliser une pierre marteau d'un ongle. Vous pouvez le faire avec une pierre, mais n'est-ce pas supposer pour utiliser le marteau qui est plus précise et plus spécifiquement conçu pour ce genre d'activité ?

Récupérer des résultats dans un classique de tableaux de mise en page est complexe et cher, parce que pour obtenir les attributs à partir de plusieurs lignes dont vous avez besoin pour faire ADHÉRER pour chaque attribut.

Ce problème peut être résolu en faisant quelques requêtes sur des données partielles et de leur transformation en tabulaire avec votre application. Même si vous disposez de 600 GO de données sur les produits, vous pouvez les traiter en lots si vous avez besoin de données à partir de chaque ligne dans cette table.

D'aller plus loin Si vous souhaitez améliorer les performances des requêtes vous pouvez sélectionner certains comme pour, par exemple, de reporting ou de texte global de la recherche et de préparer leur indice de tables qui serait de stocker les données nécessaires et serait régénéré périodiquement, par exemple toutes les 30 minutes.

Vous n'avez même pas besoin d'être préoccupés par le coût de la supplémentaire de stockage de données car il est moins cher et moins cher tous les jours.

Si vous voulez toujours être en rapport avec la performance des opérations effectuées par l'application, vous pouvez toujours utiliser Erlang, C++, Langage Go pour pré-traiter les données pour vous et à plus tard sur gérer les données renvoyées par le code de applications.

Answer 3

Si j'utilise Class Table Inheritance sens:

un tableau pour les Produits, le stockage des attributs communs à tous les types de produits. Puis une table par type de produit, le stockage des attributs spécifiques à ce type de produit. -Projet De Loi Karwin

Ce que j'aime le mieux au projet de Loi Karwin Suggestions.. je peux prévoir un inconvénient, je vais essayer d'expliquer comment éviter de devenir un problème.

Ce plan d'urgence doit, j'ai de la place quand un attribut qui est seulement commun de type 1, puis devient commune à 2, puis 3, etc?

Par exemple: (c'est juste un exemple, pas mon vrai problème)

Si nous vendre des meubles, nous pouvons vendre des chaises, des lampes, canapés, Télévision, etc. Le type de TÉLÉVISEUR peut être le seul type que nous portons qui a une consommation d'énergie. Donc, je voudrais mettre l' power_consumption l'attribut dans l' tv_type_table. Mais alors nous commençons à réaliser des systèmes de cinéma Maison, qui ont aussi un power_consumption de la propriété. OK c'est juste l'un des autres produits donc je vais ajouter ce champ dans l' stereo_type_table ainsi puisque c'est probablement la plus simple à ce point. Mais avec le temps que nous commençons à réaliser de plus en plus et de l'électronique, nous nous rendons compte qu' power_consumption est assez large qu'il devrait être dans l' main_product_table. Que dois-je faire maintenant?

Ajouter le champ à la main_product_table. Écrire un script pour faire une boucle par le biais de l'électronique et de mettre la bonne valeur de chaque type_table de la main_product_table. Puis déposez la colonne de chaque type_table.

Maintenant, Si j'ai été en utilisant toujours le même GetProductData de la classe d'interagir avec la base de données pour tirer des informations sur les produits; ainsi, si des changements dans le code maintenant besoin de refactoring, ils doivent être de la Classe seulement.

Answer 4

Vous pouvez avoir un Produit et une table séparée ProductAdditionInfo tableau avec 3 colonnes: ID de produit, pour plus d'infos, nom, complément d'info de la valeur. Si la couleur est utilisée par beaucoup, mais pas tous les types de Produits que vous pouvait-il en être nullable colonne dans la table Produit, ou tout simplement le mettre dans ProductAdditionalInfo.

Cette approche n'est pas une technique traditionnelle pour une base de données relationnelle, mais je l'ai vu beaucoup utilisé dans la pratique. Il peut être flexible et avoir de bonnes performances.

Steve Yegge appelle cela les Propriétés de modèle et a écrit un long post sur son utilisation.

Answer 5

Je me demande comment surmonter les problèmes à l'aide de Sérialisé LOB modèle comme une alternative de VAE. Supposons que l'on pourrait stocker tous les champs personnalisés de l'entité dans un champ comme une chaîne de caractères par exemple en JSON quelque chose comme tihis: {customField1: valeur1, customField2: valeur2, ..., customFieldN: valeurn}

Comment surmonter les problèmes suivants: 1. Parcourir par séparer les champs personnalisés, par exemple, de trouver des entités avec les conditions custField1 = valeur1 ET customField2 = valeur2? 2. Comment mantain l'intégrité des données, par exemple, si nous supprimer un champ personnalisé pour l'entité comment faire pour supprimer toutes les valeurs de l'oif à ces champs personnalisés dans l'entité.