Bon, de quoi parle-t-on ce coup ci ?
Le modèle de données, c’est quoi ?
Allons y 😉
Un système logiciel web est basé sur une base de données.
Cette base de données permet de stocker les informations : produits, clients, commandes, …
Le modèle de données, c’est la façon dont est organisé cette base.
Normalement, on a, par exemple, une table pour stocker l’ensemble des informations produit : prix, description, …
Le problème, c’est que, suivant les besoins, il peut être nécessaire d’ajouter des informations spécifiques.
Exemple : je vends des vélos.
Je veux ajouter, pour le rayon vélo : la taille du cadre, la taille des roues, le nombre de vitesses, avant et plateau, …
Vous voyez : on doit ajouter des attributs, spécifiques à certains produits.
On peut faire ça en modifiant la table d’origine, mais c’est pas simple :
Tous les produits n’ont pas les mêmes besoins (pour rester sur cet exemple « produit »).
Exemple : On ne peut pas ajouter la taille des roues, pour tous les produits. ça marche pour les vélos, pas pour les GPS.
De plus, cela fait modifier une table du coeur du système. Lors de la prochaine mise à jour, on va mettre à jour la table avec une nouvelle, et écraser les modifications apportée pour une boutique particulière.
La solution, proposée par Magento, est intéressante.
Ils ont appliqué le modèle EAV : Entity – Attribute – Value
Pour ceux qui veulent aller dans les détails, je vous propose d’aller voir l’article wikipedia (lien ci dessus).
L’idée est de déstructurer complètement les choses, et de coder le modèle dans les tables… Ce n’est pas très simple à expliquer simplement 😉
Bon, concrètement, dans un modèle EAV, les données sont regroupées non plus en fonction de critères d’organisation (produit, catalogue, …) mais en fonction du type de l’information stockée (entier, chaîne de caractères, …).
ça donne ça (petit bout du modèle de données) :
Ce modèle a comme immense avantage d’apporter une énorme souplesse : pour rester sur notre exemple de la base des produits, on peut définir des attributs spécifiques par produit, sans que cela impacte l’ensemble des produits de la base. Et ces modifications n’impactent pas la structure de la base : on fait ça sans ajouter de table, et sans modifier une table. On ne fait que « remplir » la base, avec les bonnes données.
Alors, c’est un monde parfait ?
Non, ça serait trop beau ;).
Ce modèle, et c’est assez évident quand on regarde le modèle général de Magento, est lourd : il « éclate » le modèle en pleins de tables. Cela a un impact sur les performances, et sur la complexité de mise à jour ou même d’accès aux données de la base.
Pour régler le problème des performances, Magento a d’ailleur introduit la notion de « table cache » qui permet de « pré calculer » certains éléments.
Update : d’après « une source bien informée », il semblerait que ce modèle EAV serait remis en question dans la prochaine release majeure : Magento 2. A suivre !
Ne vous êtes vous jamais demandé pourquoi les automates des stations essence ont une ergonomie mal fichue ?
