Entity attribut Value Database vs. strict Relational Model Ecommerce

on peut dire que le modèle de base de données EAV/CR est mauvais.

Non, ça ne l'est pas. C'est juste qu'ils sont une utilisation inefficace des bases de données relationnelles. Un magasin purement clé/valeur fonctionne très bien avec ce modèle.

maintenant, à votre vraie question: Comment stocker divers attributs et les garder consultables?

il suffit d'utiliser EAV. Dans votre cas, ce serait une seule table supplémentaire. l'indexer sur les deux attributs nom et valeur, la plupart des RDBMs utiliseraient la compression de préfixe sur l'attribut noms répétitions, ce qui le rend vraiment rapide et compact.

EAV / CR devient laid quand vous l'utilisez pour remplacer les 'vrais' champs. Comme pour tout outil, sa surutilisation est "mauvaise" et lui donne une mauvaise image.

// At this point, I'd like to take a moment to speak to you about the Magento/Adobe PSD format.
// Magento/PSD is not a good ecommerce platform/format. Magento/PSD is not even a bad ecommerce platform/format. Calling it such would be an
// insult to other bad ecommerce platform/formats, such as Zencart or OsCommerce. No, Magento/PSD is an abysmal ecommerce platform/format. Having
// worked on this code for several weeks now, my hate for Magento/PSD has grown to a raging fire
// that burns with the fierce passion of a million suns.

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

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...

Real world: je travaille sur une application midware fulfilment et voici 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'

indique l'adresse information pour une commande, par exemple

--

résumé: n'utilisez Magento que si:

1. on Vous donne de grands sacs d'argent
2. Vous devez
3. Profiter de la douleur

je suis surpris que personne n'ait mentionné NoSQL.

Je n'ai jamais pratiqué NoSQL dans un contexte de production (Je viens de tester MongoDB et j'ai été impressionné) mais tout le point de NoSQL est d'être capable de sauvegarder des articles avec des attributs variables dans le même"document".

où la performance n'est pas une exigence majeure, comme dans un type D'application ETL, L'EAV présente un autre avantage: les gains différentiels.

j'ai mis en œuvre un certain nombre d'applications où une exigence majeure était la possibilité de voir l'histoire d'un objet de domaine de sa première" version " à 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 cet objet de domaine est une personne, et j'ai 500k personnes à suivre avec une moyenne de 100+ changements au cours du cycle de vie des personnes à divers attributs. Ajoutez à cela le fait que rare est l'application qui n'a qu'un seul objet de domaine majeur et vous supposerez rapidement que la taille de la base de données serait rapidement hors de contrôle.

une solution facile est de sauver seulement les modifications différentielles à les principaux objets du domaine plutôt que de sauvegarder à répétition des informations redondantes.

tous les modèles changent au fil du temps pour refléter les nouveaux besoins opérationnels. 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".

je me bats avec le même problème. Il peut être intéressant pour vous de consulter la discussion suivante sur deux solutions de commerce électronique existantes: Magento (EAV) et Joomla (regular relational structure)): https://forum.virtuemart.net/index.php?topic=58686.0

il semble que la performance EAV de Magento soit un vrai showstopper.

C'est pourquoi je penche pour une structure normalisée. Pour surmonter le manque de flexibilité je pense à ajouter un dictionnaire de données séparé dans le futur (XML ou tables de DB séparées) qui pourrait être édité, et sur la base de cela, le code d'application pour l'affichage et la comparaison des catégories de produits avec de nouveaux ensembles d'attributs serait généré, ainsi que des scripts SQL.

une telle architecture semble être à la fois souple et performante.

le problème pourrait être l'utilisation fréquente D'ALTER TABLE en live environnement. J'utilise Postgres, donc son MVCC et son DDL transactionnel soulageront la douleur.

je vote toujours pour la modélisation au niveau atomique le plus bas-significatif pour L'EAV. Laisser les normes, les technologies et les applications qui s'orientent vers une certaine communauté d'utilisateurs pour décider des modèles de contenu, des besoins de répétition des attributs, des grains, etc.

si c'est juste au sujet des attributs de catalogue de produit et donc les exigences de validation pour ces attributs sont plutôt limités, le seul véritable inconvénient de L'EAV est la performance de requête et même qui est seulement un problème lorsque votre requête traite de multiples" choses "(produits) avec des attributs, la performance pour la requête" donnez-moi tous les attributs pour le produit avec id 234 " alors que pas optimal est encore beaucoup rapide.

une solution est d'utiliser la base de données SQL / modèle EAV seulement pour le côté admin / édition du catalogue de produits et avoir un certain processus qui dénormalise les produits en quelque chose qui le rend consultable. Puisque vous avez déjà des attributs et donc il est assez probable que vous voulez faceting, ce quelque chose pourrait être Solr ou ElasticSearch. Cette approche évite essentiellement tous les inconvénients du modèle EAV et la complexité ajoutée se limite à sérialiser un produit complet à JSON lors de la mise à jour.

VAE a de nombreux inconvénients:

1. dégradation des performances dans le temps Une fois que la quantité de données dans l'application dépasse une certaine taille, la récupération et la manipulation de ces données est susceptible de devenir de moins en moins efficace.
2. les requêtes SQL sont très complexes et difficiles à écrire.
3. problèmes D'intégrité des données. Vous ne pouvez pas définir des clés étrangères pour tous les champs nécessaires.
4. vous avez définir et maintenir vos propres métadonnées.

j'ai un problème légèrement différent: au lieu de beaucoup d'attributs avec des valeurs éparses (ce qui est peut-être une bonne raison d'utiliser EAV), je veux stocker quelque chose plus comme une feuille de calcul. Les colonnes dans la feuille peut changer, mais à l'intérieur d'une feuille toutes les cellules contiennent des données (pas rare).

j'ai fait un petit ensemble de tests pour comparer deux conceptions: l'Une utilisant EAV, et l'autre utilisant un tableau de Postgres pour stocker des données de cellules.

EAV

Array

les deux schémas ont des index sur les colonnes appropriées, et les index sont utilisés par le planificateur.

il s'est avéré que le schéma était un ordre de grandeur plus rapide pour les inserts et les requêtes. À partir de tests rapides, il semblait qui ont tous les deux escaladé linéairement. Les tests ne sont pas très approfondis. Les Suggestions et les fourchettes sont les bienvenues - elles sont sous licence MIT.