Ne peut pas prendre le crédit pour cela car il est tiré de la publication d'origine à: https://stackoverflow.com/questions/4945307/can-someone-explain-magentos-indexing-feature-in-detail
L'indexation de Magento est similaire à l'indexation au niveau de la base de données dans l'esprit. Comme le dit Anton, c'est un processus de dénormalisation pour permettre un fonctionnement plus rapide d'un site. Permettez-moi d'essayer d'expliquer certaines des pensées derrière la structure de la base de données Magento et pourquoi elle rend l'indexation nécessaire pour fonctionner à grande vitesse.
Dans une base de données MySQL plus "typique", une table de stockage des produits de catalogue serait structurée comme suit:
PRODUCT:
product_id INT
sku VARCHAR
name VARCHAR
size VARCHAR
longdesc VARCHAR
shortdesc VARCHAR
... etc ...
C'est rapide pour la récupération, mais cela laisse un problème fondamental pour un logiciel de commerce électronique: que faites-vous lorsque vous souhaitez ajouter plus d'attributs? Et si vous vendez des jouets et plutôt qu'une colonne de taille, vous avez besoin de age_range? Eh bien, vous pouvez ajouter une autre colonne, mais il doit être clair que dans un grand magasin (pensez à Walmart, par exemple), cela entraînerait des lignes vides à 90% et tenter de maintenir de nouveaux attributs est presque impossible.
Pour lutter contre ce problème, Magento divise les tables en unités plus petites. Je ne veux pas recréer l'intégralité du système EAV dans cette réponse, veuillez donc accepter ce modèle simplifié:
PRODUCT:
product_id INT
sku VARCHAR
PRODUCT_ATTRIBUTE_VALUES
product_id INT
attribute_id INT
value MISC
PRODUCT_ATTRIBUTES
attribute_id
name
Il est maintenant possible d'ajouter des attributs à volonté en entrant de nouvelles valeurs dans product_attributes puis en plaçant les enregistrements adjacents dans product_attribute_values. C'est essentiellement ce que fait Magento (avec un peu plus de respect pour les types de données que je ne l'ai montré ici). En fait, il n'y a plus de raison pour que deux produits aient des champs identiques, nous pouvons donc créer des types de produits entiers avec différents ensembles d'attributs!
Cependant, cette flexibilité a un coût. Si je veux trouver la couleur d'une chemise dans mon système (un exemple trivial), je dois trouver:
- Le product_id de l'article (dans le tableau des produits)
- L'attribut_id pour la couleur (dans la table attributaire)
- Enfin, la valeur réelle (dans la table attribute_values)
Magento fonctionnait comme ça, mais c'était très lent. Donc, pour permettre de meilleures performances, ils ont fait un compromis: une fois que le commerçant a défini les attributs qu'il veut, allez-y et générez la grande table depuis le début. Quand quelque chose change, nuke-le depuis l'espace et générez-le à nouveau. De cette façon, les données sont stockées principalement dans notre joli format flexible, mais interrogées à partir d'une seule table.
Ces tables de recherche résultantes sont les "index" de Magento. Lorsque vous réindexez, vous faites exploser l'ancienne table et la générez à nouveau.
J'espère que cela clarifie un peu les choses!