Quelqu'un peut-il expliquer en détail la fonctionnalité d'indexation de Magentos ?

L'indexation de Magento est similaire à l'indexation au niveau de la base de données dans l'esprit. Comme l'indique Anton, il s'agit d'un processus de dénormalisation pour permettre un fonctionnement plus rapide d'un site. Permettez-moi d'essayer d'expliquer certaines des réflexions derrière la structure de la base de données Magento et pourquoi elle rend l'indexation nécessaire pour fonctionner rapidement.

Dans une base de données MySQL plus "typique", une table pour stocker les produits du 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 pourriez ajouter une autre colonne, mais il devrait être clair que dans un grand magasin (pensez à Walmart, par exemple), cela se traduirait par des lignes vides à 90 % et qu'il serait presque impossible de maintenir de nouveaux attributs.

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 désormais possible d'ajouter des attributs à volonté en saisissant 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 ce que j'ai montré ici). En fait, il n'y a plus aucune 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 color d'une chemise dans mon système (un exemple trivial), je dois trouver :

1. Le product_id de l'article (dans la table des produits)
2. Le attribute_id pour color (dans la table attributaire)
3. Enfin, la value réelle (dans la table des valeurs_attributs)

Magento fonctionnait comme ça, mais c'était très lent. Alors, pour permettre de meilleures performances, ils ont fait un compromis :une fois que le propriétaire de la boutique a défini les attributs qu'il souhaite, continuez et générez la grande table depuis le début. Lorsque quelque chose change, lancez-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" Magento. Lorsque vous réindexez, vous agrandissez l'ancienne table et la générez à nouveau.

J'espère que cela clarifie un peu les choses !

Merci, Joe