Ces cas sont gérés, dans un modèle classique, avec des tables supplémentaires et qui finissent par alourdir également le code, les requêtes et la base de données. Le modèle EAV plus souple permet de les stocker dans les mêmes tables en les typant simplement sans grosses modifications du code et des requêtes…

Lavoisier disait : »Rien ne se perd, rien ne se crée, tout se transforme. » Je dirais en conclusion que pour répondre à une base de données simple, un modèle flat classique est bien plus performant, mais dans le cas contraire si on veut du multivalué, du multi-versionning, du multilingue, etc… les deux modèles aboutissent aux même résultats = Complexité et lourdeur.

Pour ma part, je préfère EAV pour sa souplesse anticipant la gestion des cas les plus complexes auxquelles on fini toujours par être confronté un jour ou l’autre dans tout projet informatique de long terme.

Mon expérience dans le logiciel est que si un client vous dit : »non je n’ai pas besoins du multilingues et je n’en aurais jamais besoins » => prévoyez le dans votre modèle de données ! car c’est la première évolution que votre client vous demandera… La loi de Murphy est une règle a prendre en compte dans notre métier !

Il faudrait donc apporter une réponse aux deux cas de figure selon les besoins des utilisateurs.
C’est en fait ce que nous avons fait en tant qu’étideur dans notre solution de Web Database qui a comme objectif de permettre de créer des applications de base de données simples ou complexes sans avoir a ce soucier du modèle de données. Bref un framework EAV et/ou CLASSIQUE.

Didier

Bonjour,

Merci pour ce commentaire particulièrement complet.
Effectivement j’utilise une 1.4.x ce qui explique cette inexactitude.

Je vais modifier l’article très rapidement.

Merci

Il y a quelques inexactitudes dans cet article.
Ce qui me saute aux yeux c’est l’eav au niveau des orders. Je suis désolé de l’annoncer mais ça a été retiré depuis la version 1.4.0.1. Depuis toutes les tables de type order/entity ont été remplacées par des tables de type flat/order (bien qu’il reste des résidus dans les tables eav_*)

Donc il reste de l’eav pour 4 éléments : customer, customer_address, catalog_category, catalog_product. Pour customer/customer_address, l’eav est discutable. Certes il ralenti la lecture (avec toute cette pléthore de ‘join’ niveau SQL), mais ça reste raisonnable, et permet de ce fait une modularité des attributs client. Sans grande importance donc.

En l’occurrence là où l’eav pèche bien évidement, c’est au niveau du catalogue. Bien que très modulaire, il ralenti considérablement le site (cf l’article) à partir d’un certain nombre de produits, surtout couplé avec différents stores. L’indexer est une solution, mais à mon avis pas viable puisqu’il implique des traitements doubles (eav et flat). Il n’y a donc pour le moment pas de solution et ils n’annoncent malheureusement pas de changements à ce niveau avec Magento 2 qui doit probablement être du à un retour arrière très complexe.
A voir donc 🙂

La modification de structure d’une base en production ne doit bien sur pas être réalisée en pleine charge. C’est une opération qui présente toujours un risque et j’imagine que le moindre Alter Table en production risque de demander un recalcul des index de la table (il est préférable de lancer ce type d’opération sur un replica de la base). Ce type de modification devraient être planifiées et mise en oeuvre en période creuse (si si, la nuit, il ne faut pas dormir :-)). Globalement que ce soit en EAV ou une modification de structure, les changements « intempestifs » sont très coûteux. Sur Magento, le prix à payer est souvent de re-créer les index, ce qui sur une base lourde est très long.

Sinon je ne me suis pas trop penché sur la question, mais quels sont les risques de modification de structures intempestives (les attributs produits doivent pouvoir être manipulés facilement) sur une bdd massive en prod?