Infocurci - programmatore Php Roma
Infocurci - programmatore Php Roma
Questo sito non lascia nessun cookie sul vostro pc, consuma pochissimi kb, non profila nulla e non raccoglie dati personali. Siete i benvenuti.

Magento : La struttura del database: anagrafica prodotti

La tabella "catalog_product_entity" rappresenta la base del modello EAV, il cuore di Magento. Inizia da qui una serie di tutoria con i quali andremo a fondo nella struttura della base dati del software, avendo cosi modo di scoprire altri aspetti che è bene non dare per scontati.

Magento

Inizia qui una serie di articoli dedicati al cuore di Magento: la struttura del database. Conoscere l'organizzazione delle tabelle ci consentirà di lavorare meglio nella risoluzione di problematiche (capita raramente ma anche Magento ha i suoi bug), nella progettazione di nuovi componenti e perché no nella scrittura di workaround. Sò che i puristi storceranno il naso ma in alcuni casi un workaround può essere una soluzione assai efficace. Proprio in questi giorni ho dovuto sviluppare un processo che, di notte, si collega ad un feed xml e di conseguenza aggiorna il database Magento con i prodotti. Ho elaborato un processo standard, un cronjob con le librerie di Magento, funzionale ma troppo lento. Il feed in questione è capace di contenere anche 20mila prodotti, sul server del cliente la procedura Magento $product->save() impiegava in media 1 secondo, fate la moltiplicazione e vedete da voi quanto percorribile fosse quella strada.
Iniziamo quindi il nostro viaggio dalla tabella base: catalog_product_entity. Questa tabella mette in relazione il modello di un prodotto, campo "sku", con una chiave id auto-increment "entity_id". Attenzione: il campo Sku, almeno a livello di database, non è univoco. A livello di software Magento l'inserimento di uno sku duplicato viene bloccato da appositi controlli php ma questo non impedisce l'inserimento accidentale attraverso codice diretto.. teniamolo ben presente se dobbiamo sviluppare processi di sincronizzazione magazzino o altro, l'insert di uno sku già esistente non genera errore nel database. Il campo va mantenuto univoco perché la funzione getIdBySku() è a dir poco vitale per il catalogo di Magento.
I campi entity_type_id e attribute_set_id negli ecommerce meno complessi mantengono sempre gli stessi valori, di solito "4". Il primo campo infatti si relaziona con la tabella "eav_entity_type", definisce cioè il tipo di entità dei dati -Magento usa il pattern EAV- il cui id 4 corrisponde a "catalog_product".
Il campo "attribute_set_id" invece si riferisce al set di attributi prodotto (nome, colore, taglia, descrizione ecc). Il set di default, pre-installato in Magento, di solito ha anch'esso id 4; sta poi all'amministratore decidere se usarlo, aggiungere campi o crearne di nuovi.
Infine ecco i 3 campi meno comprensibili, almeno a prima vista, della tabella: type_id, has_options,required_options.
Il type_id è un campo di tipo varchar ma possiamo considerarlo -per quello che è l'utilizzo che ne viene fatto in Magento- come un campo ENUM, visto che contiene un set predefinito di tipologia di prodotto. Al momento Magento supporta questi tipi di prodotto:

  • simple (il label nelle versioni italiane è "semplice"): prodotto base, "fisico" (venduto di solito a pezzi) e come tale da consegnare al cliente attraverso spedizione o ritiro in sede.
  • grouped (raggruppato): prodotto che raggruppa sotto-prodotti molto simili tra loro (esempio un lettore mp3 disponibile in più modelli differenti per memoria installata)
  • configurable (configurabile): prodotto con più varianti (classico esempio quello di taglie e colori, ma su questo torneremo tra poco)
  • virtual (virtuale): è un servizio, come può essere una riparazione, una garanzia, un'assistenza; ovviamente non richiede spedizione o magazzino.
  • bundle: prodotto configurabile, come un computer non assemblato per il quale l'utente sceglie schede, case, espansioni
  • downloadable (scaricabile): è un prodotto digitale, come un pdf o un brano musicale. Importante: il file può essere ospitato anche su un server esterno

Spesso nelle guide, sopratutto in quelle italiane, si legge che i prodotti configurable vanno usati per gestire taglie e colori. Vero ma non sempre, a me capita spesso in queste occasioni di usare prodotti di tipo grouped. La vera differenza tra grouped e configurable è questa:
- un prodotto "grouped" raggruppa più prodotti in una pagina consentendo di selezionarne più di uno alla volta;
- un prodotto "configurable" raggruppa più prodotti in una pagina consentendo di selezionarne uno alla volta
Per cui, per ecommerce all'ingrosso, come store di abbigliamento in cui l'acquirente compra più taglie e colori di uno stesso capo d'abbigliamento, consiglio di usare prodotti di tipo grouped.
Per un ecommerce di vestiti al dettaglio nel quale ci si aspetta che un utente acquisti 1 modello di maglione o pantalone alla volta, consiglio di usare prodotti configurable.