Entité attribut valeur base de données vs stricte question de Ecommerce de modèle relationnel

Question

Il est sûr de dire que les EAV/CR modèle de base de données est mauvais. Cela dit,

Question: Ce modèle de base de données, la technique, ou modèle doit être utilisé pour traiter les "classes" d'attributs décrivant les produits de commerce électronique qui peut être modifié au moment de l'exécution?

Dans une bonne E-commerce, base de données permet de stocker les classes d'options (comme la résolution de TV alors une résolution pour chaque PLAT, mais le produit peut ne pas être d'une TÉLÉVISION et de ne pas avoir "la résolution de TV"). Comment voulez-vous de les stocker, de rechercher de manière efficace, et permettre à vos utilisateurs de configuration des types de produit avec des champs variables décrivant leurs produits? Si le moteur de recherche ne trouve que les clients sont généralement à la recherche pour les Téléviseurs basés sur la console de profondeur, vous pouvez ajouter de la console de la profondeur à vos champs, puis ajouter une profondeur unique pour chaque plat type de produit au moment de l'exécution.

Il y a une belle caractéristique commune parmi les bons e-commerce applications où ils montrent un ensemble de produits, puis de "drill down" côté des menus où vous pouvez voir "Résolution de TV" comme en-tête, et le top cinq des plus communs de la TÉLÉVISION Résolutions pour l'ensemble trouvé. Vous cliquez sur l'un et il affiche uniquement les Téléviseurs de cette résolution, vous permettant de forage supplémentaires vers le bas en sélectionnant d'autres catégories dans le menu latéral. Ces options serait la dynamique des attributs des produits ajoutés au moment de l'exécution.

La poursuite de la discussion:

Donc, c'est une longue histoire courte, existe-il des liens sur l'Internet ou les descriptions de modèle qui pourrait "académique" corriger la configuration suivante? Je remercie Noel Kennedy pour suggérant une catégorie de la table, mais le besoin d'être plus grand que cela. Je décris une manière différente, ci-dessous, en essayant de mettre en évidence l'importance. J'ai peut-être besoin d'un point de vue de la correction de résoudre le problème, ou j'ai peut-être besoin d'aller plus profond dans l'EAV/CR.

L'amour de la réponse positive de l'EAV/CR modèle. Mes collègues développeurs disent tous ce que Jeffrey Kemp abordé ci-dessous: "de nouvelles entités doivent être modélisés et conçu par un professionnel" (prises hors de leur contexte, la lecture de sa réponse ci-dessous). Le problème, c'est:

• les entités d'ajouter et de supprimer des attributs hebdomadaire
  (mots-clés de recherche dicter attributs)
• de nouvelles entités arriver hebdomadaire
  (les produits sont assemblés à partir de pièces)
• vieux entités aller loin hebdomadaire
  (archivé, de moins en moins populaire, de saison)

Le client veut ajouter des attributs pour les produits pour deux raisons:

• département / recherche par mot-clé / tableau de comparaison entre des produits similaires
• des produits de consommation de configuration avant de valider votre commande

Les attributs doivent avoir une signification, et pas seulement un mot-clé de recherche. Si ils veulent comparer tous les gâteaux qui ont une "crème fouettée glaçage", ils peuvent cliquer sur les gâteaux, cliquez sur anniversaire à thème, cliquez sur la crème fouettée glaçage, puis cochez tous les gâteaux qui sont intéressantes, sachant qu'ils ont tous la crème fouettée glaçage. Ce n'est pas spécifique à gâteaux, juste un exemple.

Answer 1

Il y a quelques avantages et les inconvénients que je pense, il y a des situations où l'une est meilleure que l'autre:

L'Option 1, Modèle EAV:

• Pro: moins de temps pour concevoir et développer une application simple
• Pro: de nouvelles entités facile d'ajouter (pourrait même être ajoutés par les utilisateurs?)
• Pro: "génériques" des composants de l'interface
• Con: code complexe nécessaire pour valider les types de données simples
• Con: beaucoup plus complexe SQL pour de simples les rapports
• Con: des rapports complexes peuvent devenir presque impossible
• Con: des performances médiocres pour les grands ensembles de données

L'Option 2, la Modélisation de chaque entité séparément:

• Con: plus le temps nécessaire pour rassembler exigences de conception et d'
• Con: de nouvelles entités doivent être modélisées et conçu par un professionnel
• Con: les composants de l'interface pour chaque entité
• Pro: type de données de contraintes et de validation simple à mettre en œuvre
• Pro: SQL est facile à écrire, facile à comprendre et de débogage
• Pro: même les plus complexes, les rapports sont relativement simples
• Pro: meilleure performance pour les grands ensembles de données

L'Option 3, la Combinaison (entités du modèle "correctement", mais ajoutez "extensions" pour les attributs personnalisés pour certaines/toutes les entités)

• Pro/Con: plus le temps nécessaire pour recueillir les exigences et la conception que l'option 1, mais peut-être pas autant que l'option 2 *
• Con: de nouvelles entités doivent être modélisées et conçu par un professionnel
• Pro: de nouveaux attributs peuvent être facilement ajoutés plus tard
• Con: code complexe nécessaire pour valider les types de données simples (pour les attributs personnalisés)
• Con: les composants de l'interface toujours nécessaire, mais génériques des composants de l'interface peut être possible pour les attributs personnalisés
• Con: SQL devient complexe dès que l'attribut personnalisé est inclus dans un rapport
• Con: de bonnes performances en général, à moins que vous n'ayez besoin de les rechercher par ou un rapport par les attributs personnalisés

* Je ne suis pas sûr si l'Option 3 serait nécessairement sauver du temps dans la phase de conception.

Personnellement, je pencherais vers l'option 2, et d'éviter la VAE dans la mesure du possible. Cependant, pour certains scénarios, les utilisateurs ont besoin de la flexibilité qui vient avec la VAE; mais cela vient avec un grand coût.

Answer 2

Il est sûr de dire que les EAV/CR modèle de base de données est mauvais.

Non, il n'est pas. C'est juste qu'ils sont une utilisation inefficace des bases de données relationnelles. Purement clé/valeur en magasin fonctionne très bien avec ce modèle.

Maintenant, à votre question: Comment faire pour stocker différents attributs et de les garder-ils consultables?

Suffit d'utiliser la VAE. Dans votre cas, il serait une seule et unique table supplémentaire. indice sur le nom de l'attribut et la valeur, la plupart des Sgbdr serait d'utiliser le préfixe de compression sur le nom de l'attribut de répétitions, le rendant vraiment rapide et compact.

EAV/CR devient laid quand vous l'utiliser pour remplacer le 'réel' des champs. Comme tout outil, le gaspillage, il est "mauvais", et il donne une mauvaise image.

Answer 3

Je suis surpris que personne ne mentionne les bases de données NoSQL.

Je n’ai jamais pratiqué de NoSQL dans un contexte de production (juste examiné MongoDB et a été impressionné), mais le point entier de NoSQL est d’être capable d’enregistrer des éléments avec des attributs différents dans le même « document ».

Answer 4

// À ce moment, je voudrais prendre un moment pour vous parler de la Magento/Adobe format PSD.
// Magento/PSD n'est pas une bonne plateforme de commerce électronique/format. Magento/PSD n'est même pas une mauvaise plateforme de commerce électronique/format. L'appelant serait un
// insulte à d'autres mauvais plateforme de commerce électronique/formats, tels que Zencart ou OsCommerce. Non, Magento/PSD est un insondable plateforme de commerce électronique/format. Avoir
// travaillé sur ce code pour plusieurs semaines maintenant, ma haine pour Magento/PSD a augmenté à un incendie fait rage
// qui brûle avec l'ardeur de la passion d'un million de soleils.

http://code.google.com/p/xee/source/browse/trunk/XeePhotoshopLoader.m?spec=svn28&r=11#107

Les modèles internes sont farfelus, au mieux, comme quelqu'un a mis le schéma dans un boggle jeu, scellé et mis dans une peinture shacker...

Monde réel: je suis en train de travailler sur un midware exécution de l'app et voici l'une des requêtes pour obtenir des informations d'adresse.

CREATE OR REPLACE VIEW sales_flat_addresses AS
SELECT sales_order_entity.parent_id AS order_id, 
       sales_order_entity.entity_id, 
       CONCAT(CONCAT(UCASE(MID(sales_order_entity_varchar.value,1,1)),MID(sales_order_entity_varchar.value,2)), "Address") as type, 
       GROUP_CONCAT( 
         CONCAT( eav_attribute.attribute_code," ::::: ", sales_order_entity_varchar.value )
         ORDER BY sales_order_entity_varchar.value DESC
         SEPARATOR '!!!!!' 
       ) as data
  FROM sales_order_entity
       INNER JOIN sales_order_entity_varchar ON sales_order_entity_varchar.entity_id = sales_order_entity.entity_id
       INNER JOIN eav_attribute ON eav_attribute.attribute_id = sales_order_entity_varchar.attribute_id
   AND sales_order_entity.entity_type_id =12
 GROUP BY sales_order_entity.entity_id
 ORDER BY eav_attribute.attribute_code = 'address_type'

Exige des informations d'adresse pour une commande, paresseusement

--

Résumé: Seule l'utilisation de Magento si:

1. On vous donne de grands sacs d'argent
2. Vous devez
3. Profitez de la douleur

Answer 5

Où la performance n'est pas une exigence majeure, comme dans un ETL type d'application, la VAE a un autre avantage: différentiel sauve.

J'ai mis en place un certain nombre d'applications où une ardente obligation a été la capacité de voir l'histoire d'un objet de domaine à partir de sa première "version" de son état actuel. Si l'objet de domaine a un grand nombre d'attributs, cela signifie que chaque changement nécessite une nouvelle ligne être inséré dans la table correspondante (pas une mise à jour, parce que l'histoire serait perdu, mais un insert). Disons que ce domaine de l'objet est une Personne, et j'ai 500k Personnes à suivre avec une moyenne de+ de 100 modifications sur les Personnes du cycle de vie de divers attributs. Ajoutez à cela le fait que rare, c'est l'application qui a seulement 1 domaine principal objet et vous allez vite surmize que la taille de la base de données devrait rapidement se développer hors de contrôle.

Une solution simple est d'enregistrer seulement les changements différentiels pour les principaux objets de domaine plutôt qu'à plusieurs reprises économie de l'information redondante.

Tous les modèles de changement au fil du temps pour tenir compte des nouveaux besoins de l'entreprise. Période. À l'aide de la VAE est un des outils dans notre boîte à utiliser; mais il ne doit jamais être automatiquement classé comme "mauvais".