Magento : La struttura del database: le tabelle dei prodotti

Nello scorso articolo abbiamo avuto modo di studiare la struttura della tabella principale dei prodotti di Magento, "catalog_product_entity". Proseguiamo oggi il nostro percorso in maniera più rapida analizzando tutte le altre tabelle, per le quali non è necessario fermarsi in maniera specifica su ogni campo. Magento infatti basa la propria struttura dati sul modello EAV entity-attribute-value, quindi il fatto che esistano decine e decine di tabelle con prefisso "catalog_product" non deve preoccuparci oltremodo riguardo la complessità del db.
Procediamo pure in ordine alfabetico, individuando un elenco di tabelle che iniziano per "catalog_product_bundle". Queste tabelle si occupano dei prodotti di tipo bundle, che rappresentano articoli configurabili per i quali un utente può decidere di personalizzare vari componenti; classico esempio quello degli store che permettono di scegliere le varie parti di un pc da assemblare. Ponete particolare attenzione sulla tabella catalog_product_bundle_stock_index che contiene lo stock di ogni singolo componente del prodotto: come è giusto che sia - giusto ma non scontato, almeno per il panorama attuale degli ecommerce open source-, Magento consente di gestire la disponibilità di ogni pezzo che compone il "bundle".
Troviamo poi la tabella "catalog_product_enabled_index" che secondo la documentazione ufficiale "defines the visibility status of a product entity in the Magento stores". In realtà su ecommerce con un unico store, la tabella rimane sempre vuota.
Segue poi l'elenco di tutte le tabelle "catalog_product_entity" riferite al modello EAV, per cui ne troviamo una per i valori data, una per le stringhe, una per i decimali e via dicendo. Gallery/media, prezzi e relativi gruppi hanno tabelle dedicate. A questo proposito vi segnalo che "catalog_product_entity_tier_price" contiene i prezzi di tipo tier,  che consentono di applicare sconti per quantità di merce inserita in carrello e per gruppi di utenti. Non vi nascondo che mi è capitato di intervenire in maniera diretta su questa tabella quando ho avuto a che fare con procedure di sincronizzazione di prezzi che andavano eseguite con una certa rapidità e frequenza, bypassando cosi la gestione di Magento attraverso un cronjob dedicato. Ovviamente è una soluzione logica solo in alcuni casi, ma posso confermarvi che la tabella accetta scritture "brutali".
Veniamo poi alla tabella "catalog_product_flat_1", che introduce al discorso dei prodotti flat su Magento. Il modello EAV consente di creare schede prodotto espandibili in maniera esponenziale: ciascun amministratore di un negozio Magento può decidere quali e quanti campi inserire nella scheda di un prodotto. Questa flessibilità ha l'altra faccia della medaglia nella lentezza delle numerose query necessarie per ricostruire i vari campi Grazie ai prodotti flat Magento ricostruisce tutti i dati in un'unica tabella con ovvie conseguenze in termini di prestazioni.
La tabella in questione si chiama "catalog_product_flat_", seguita da un indice numerico riguardante il nostro store (nelle installazioni utilizzate per gestire un unico negozio avrà di solito valore 1).
Aprendo la tabella possiamo riconoscere agevolmente nella struttura i campi fondamentali di un prodotto, dal codice sku al prezzo, dalle immagini allo snippet usato per la sovrascrittura delle url.
Per attivare i prodotti Flat nel nostro store, dobbiamo seguire questi semplici passaggi:

 

1. entriamo nel pannello di amministrazione e quindi in "system" / "configuration"
2. a sinistra, scegliemo "catalog" (sotto "catalog")
3. in frontend, impostiamo "Use Flat Catalog Category" e "Use Flat Catalog Product" su Yes e salviamo. A quel punto ci verrà richiesto di aggiornare gli indici, cosa che andremo a fare immediatamente.

L'opzione di utilizzare il flat per le categorie è consigliabile in qualsiasi magento, mentre quella di usare il flat per i prodotti produce benefici più che altro per negozi con più di 1000 articoli.
L'enorme elenco di tabelle "catalog_product_index" serve per tenere aggiornate le varie correlazioni del modello EAV, per cui possiamo evitare di  usarle in maniera diretta nel nostro software, delegandone la gestione alle comode funzioni di Magento di cui parleremo in un futuro articolo.
Le tabelle "catalog_product_link" sono molto interessanti perché contengono tutte le correlazioni tra prodotti. Sappiamo che Magento supporta questi tipi di correlazioni tra prodotti:

1. relation, riferita ai "related products"  (in italiano "prodotti correlati"). Sono prodotti strettamente legati tra loro per via di un utilizzo complementare, come può essere una custodia o un caricabatteria che appare sulla scheda di uno smartphone;
2. up_sell, sono prodotti simili a quello in questione ma di fascia più alta. Ad esempio sulla scheda di un lettore mp3 da 16 giga, questa funzione consente di far apparire lo stesso modello ma con 32 giga oppure un modello diverso con stessa memoria ma con l'aggiunta della radio Fm.
3. cross_sell, sono simili ai prodotti correlati ma hanno un legame meno vincolante. Mentre un correlato può essere un caricatore per un telefonino (ognuno necessita di uno ben preciso), un cross-sell è ad esempio un videogioco che appare sulla pagina di una console
4. Esiste un quarto indice, "super", che memorizza le relazioni tra un prodotto di tipo grouped e i relativi sotto-prodotti. Quest'ultima relazione è replicata anche nella tabella "catalog_product_relation".

In "catalog_product_option" (6 tabelle in tutto con questo prefisso) abbiamo invece la base dati per la gestione della voce "custom options", che ci consente di applicare varianti a pagamento ad un singolo pezzo.
Le tabelle "catalog_product_super" (4 tabelle) gestiscono i prodotti configurabili e sopratutto le relative varianti, ciascuna con (eventuale) differenza di prezzo rispetto all'articolo base.
Infine, la classica tabella "catalog_product_website"  associa un id prodotto al relativo store, è sempre compilata anche se Magento viene installato per gestire un unico negozio.