Dois-je utiliser le modèle EAV?

Question

Je suis de la conception de ma base de données/domaine pour une application eCommerce et je vais avoir un moment difficile de déterminer comment les produits de la boutique.

Le site web permettra de vendre une large gamme de produits, des stylos, des lanières, des tatouages, des parasols, des tout. Chacun de ces produits va partager quelques attributs communs, la hauteur, la largeur, la longueur, le poids, etc, mais certains produits ont des données spéciales. Par exemple, les stylos ont différentes couleurs d'encre et des conseils et des couvercles et des brochures de différents types de plis. Jusqu'à présent, j'ai pensé à quelques 20+ attributs supplémentaires, mais ces attributs peuvent ne s'appliquer qu'à 1% des produits sur le site.

Donc je me demande si c'est approprié pour mettre en œuvre un modèle EAV pour gérer les données supplémentaires. En gardant à l'esprit que lorsque les clients sont à consulter le site dans le frontend, il y aura un filtrage barre latérale, comme sur eBay et carsales.com.de l'ua. (Donc en gardant à l'esprit qu'il sera un peu juste de l'interrogation)

Je ne pense pas que c'est pratique à mettre en œuvre en Classe de l'héritage de Table comme le système doit rester souple. C'est parce que, en bas de la piste on peut avoir plusieurs attributs dans le futur avec de nouveaux types de produits.

L'autre chose que j'ai considéré est l'aide d'une base de données NoSQL (probablement MongoDB) cependant j'ai peu d'expérience avec ces types de bases de données, mettra à même de résoudre mon problème?

L'examen des options:

1. Unique entité de produits avec beaucoup de colonnes
2. Séparer les attributs de l'entité (VAE)
3. Commutateur de schéma de persistance

Je suis dans le processus de construction d'un prototype avec un des attributs de l'entité de voir comment flexible, il est, et de tester les performances et la façon dont le contrôle de l'interrogation obtient.

EDIT: je suis bien sûr ouverte à toutes les autres solutions.

Answer 1

La grande question, mais bien sûr, il n'y a pas de "vraie voie". Comme par @BenV, Magento utilise le modèle EAV. Mon expérience a été très positive, mais il le fait le voyage jusqu'à d'autres utilisateurs. Quelques considérations:

1. Les performances. VAE nécessite complexe, multi-jointures de table pour remplir votre objet avec les attributs pertinents. Que fait encourir un gain de performance. Cependant, qui peut être atténué grâce à une mise en cache (à tous les niveaux par le biais de la pile, y compris la mise en cache de requêtes) et l'utilisation sélective de la dénormalisation. Magento ne permettent aux administrateurs de sélectionner un dénormalisée modèle pour les catégories et les produits où le nombre d'Ugs le justifie (généralement dans les milliers). Qui à son tour nécessite des Observateurs de déclenchement de la ré-indexation (toujours bon!) et les mises à jour "à plat" dénormalisée tables lorsque le produit des modifications de données. Qui peut également être programmée ou déclenchée manuellement avec un message à l'administrateur.

2. 3ème Partie de la Complexité de l'Utilisateur Si jamais vous prévoyez de faire cette application disponible pour les autres utilisateurs, de nombreux trouverez EAV trop complexe et vous aurez affaire à beaucoup de bêlements et mal informés, les abus sur les forums d'utilisateurs (réf Magento!!).

3. L'avenir de l'extensibilité et de l'architecture de plugin. Il ne fait aucun doute que le modèle EAV vient vraiment dans son propre quand il est extensibilité est un facteur. Il est très simple d'ajouter de nouveaux attributs dans le modèle, tout en minimisant le risque de rupture existants ORM et le code du contrôleur.

4. Les changements dans le type de données La VAE est un peu plus difficile à modifier l'attribut type de données. Si votre conception initiale des appels pour un attribut de type de données que les changements dans l'avenir (disons int de varchar), cela signifie que vous aurez à faire migrer tous les enregistrements pour cet attribut correspondant de la table qui correspond au nouveau type de données. Bien sûr, les puristes vous suggérons de faire la première fois, mais la réalité n'empiètent parfois!

5. Manuel des importations de produits Une chose que EAV rend presque impossible l'importation de produits (ou d'autres entités) dans la base de données à l'aide de SQL et/ou phpMyAdmin style CSV/XML. Vous aurez besoin de rédiger un Importateur module qui accepte les données structurées et les transmet par le biais de l'application de la couche de Modèle à persister dans la base de données. Qui ne s'ajouter à votre complexité.

Answer 2

Le panier d'achat open source Magento permet des attributs personnalisés pour leurs produits en utilisant une conception EAV. Vous pouvez consulter leur schéma de base de données ici .

Answer 3

Je vous suggère de regarder de plus près sur Doctrine 2 ORM avec le plugin OXM pour cela (https://github.com/doctrine/oxm). Il résoudra votre problème avec différents attributs. Bien sûr, vous devrez créer des index pour les attributs personnalisés consultables, mais je ne pense pas que ce sera un problème :)

Si vous ne vous souciez pas du nombre de membres de la communauté, vous pouvez également utiliser MongoDB.