Magentos indeksering ligner kun indeksering på databaseniveau i ånden. Som Anton siger, er det en denormaliseringsproces for at tillade hurtigere drift af et websted. Lad mig prøve at forklare nogle af tankerne bag Magento-databasestrukturen, og hvorfor den gør indeksering nødvendig for at fungere med hastighed.
I en mere "typisk" MySQL-database vil en tabel til lagring af katalogprodukter være struktureret sådan her:
PRODUCT:
product_id INT
sku VARCHAR
name VARCHAR
size VARCHAR
longdesc VARCHAR
shortdesc VARCHAR
... etc ...
Dette er hurtigt at hente, men det efterlader et grundlæggende problem for et stykke e-handelssoftware:hvad gør du, når du vil tilføje flere attributter? Hvad hvis du sælger legetøj, og i stedet for en størrelseskolonne har du brug for age_range
? Nå, du kunne tilføje en anden kolonne, men det burde være klart, at i en stor butik (tænk f.eks. Walmart), ville dette resultere i rækker, der er 90 % tomme, og forsøg på at vedligeholde nye attributter er næsten umuligt.
For at bekæmpe dette problem opdeler Magento tabeller i mindre enheder. Jeg ønsker ikke at genskabe hele EAV-systemet i dette svar, så accepter venligst denne forenklede model:
PRODUCT:
product_id INT
sku VARCHAR
PRODUCT_ATTRIBUTE_VALUES
product_id INT
attribute_id INT
value MISC
PRODUCT_ATTRIBUTES
attribute_id
name
Nu er det muligt at tilføje attributter efter behag ved at indtaste nye værdier i product_attributes
og derefter indsætte tilstødende poster i product_attribute_values
. Dette er dybest set, hvad Magento gør (med lidt mere respekt for datatyper, end jeg har vist her). Faktisk er der nu ingen grund til, at to produkter overhovedet skal have identiske felter, så vi kan oprette hele produkttyper med forskellige sæt attributter!
Denne fleksibilitet har dog en omkostning. Hvis jeg vil finde color
af en skjorte i mit system (et trivielt eksempel), skal jeg finde:
product_id
af varen (i produkttabellen)attribute_id
forcolor
(i attributtabellen)- Til sidst den faktiske
value
(i tabellen attributværdier)
Magento plejede at arbejde sådan her, men det var død langsomt. Så for at tillade bedre ydeevne indgik de et kompromis:Når butiksejeren har defineret de egenskaber, de ønsker, skal du gå videre og generere det store bord fra begyndelsen. Når noget ændrer sig, skal du nuke det fra rummet og generere det igen. På den måde lagres data primært i vores flotte fleksible format, men forespørges fra en enkelt tabel.
Disse resulterende opslagstabeller er Magento "indekser". Når du genindekserer, sprænger du den gamle tabel og genererer den igen.
Håber det afklarer tingene lidt!
Tak, Joe