Tra le tante cose di cui si parla riguardo WordPress, un aspetto particolarmente critico è legato alla strategia con cui sono memorizzati i dati all’interno del database, e che viene chiamata comunemente EAV. Questa strategia offre vantaggi in fase di inserimento dei dati, ma crea diverse problematiche nelle fasi successive. Si può pensare di risolvere questi problemi soltanto con un approccio differente alle tabelle, il che presuppone di riscrivere il codice di vari plugin, spesso con vantaggi relativi e difficilmente misurabili.
Cos’è EAV
WordPress tende ad usare massicciamente il database, e non solo per memorizzare post: anche per memorizzare pagine statiche, allegati, URL di immagini, tipi personalizzati, dati di Woocommerce e cosଠvia. Questa sovrastruttura del tutto generica offre il vantaggio di essere riconoscibile da qualsiasi programmatore, a patto che lo stesso sia skillato e sia disposto a procedere ad un livello di coding differente da quello a cui potrebbe essere abituato in altri contesti (Java, ecc.).
Senza scendere in troppi dettagli tecnici, la scelta di usare EAV si traduce nel fatto che invece di usare una colonna per attributo, ad esempio:
(1,mario,rossi,50,M)
dove le colonne sono (id, nome, cognome, eta, sesso), si preferisce una struttura ad attributi:
(…,1,nome,mario)
(…,1,cognome,rossi)
(…,1,eta,19)
(…,1,sesso,M)
il che in prima istanza aumenta la complessità spaziale (i dati occupano più spazio) e sembra una complicazione quasi inutile rispetto alla precedente. Prima di giudicarla, pero’, credo sia necessario capire le motivazioni che sono alla sua base.
Il modello Entità -Attributo-Variabile (o Entity-Attribute-Value, in sigla EAV, nota anche come object–attribute–value model, vertical database model e open schema.) rappresenta il layout di dati a cui il database si ispira a livello di architettura, e che in parta richiama le strutture matematiche note come “matrici sparse” (matrici in cui sono memorizzati solo i valori diversi da zero). Il vantaggio di questa scelta, incomprensibile a molti per la verità , è legato al fatto che in WordPress puoi memorizzare qualsiasi numero di colonne – ad esempio entità con 10, 100 o 1000 colonne – semplicemente sfruttando altrettante righe e vincolando le tue operazioni a coppie (chiave, valore).
In altri termini, se normalmente andremmo a memorizzare i dati (ad esempio dei nostri utenti) seguento uno schema lineare (tabella clienti):
| userid | nome | cognome | eta | sesso |
| 1 | Mario | Rossi | 19 | M |
| 2 | Maria | Bianchi | 25 | F |
con il modello EAV gli stessi dati sono salvati cosଠ(tabella clienti_eav):
| meta_id | customer_id | meta_key | meta_value |
| 1 | 1 | nome | Mario |
| 2 | 1 | cognome | Rossi |
| 3 | 1 | eta | 19 |
| 4 | 1 | sesso | M |
| 5 | 2 | nome | Maria |
| 6 | 2 | cognome | Bianchi |
| 7 | 2 | eta | 25 |
| 8 | 2 | sesso | F |
con l’unica accortezza di usare un doppio ID: il primo meta_id è la chiave primaria della colonna, il secondo customer_id è l’identificativo dell’oggetto. In pratica una serie di coppie chiave, valore (ovvero meta_key, meta_value) che ogni persona che abbia sviluppato decentemente su WordPress dovrebbe conoscere. Questo significa che lo schema logico dei dati non corrisponde con quello fisico che uno si aspetterebbe, ed assume che i meta dati abbiano un’importanza basilare, tanto da diventare prioritari rispetto al resto.
Se è vero che ciò si traduce in una sostanziale scarsa efficenza delle operazioni su database (nel primo caso sarebbe bastata una SELECT lineare, nel secondo servono query con JOIN), rimane un modello ottimo per via della sua genericità , e per il fatto che permette di memorizzare dati di qualsiasi tipo, in modo flessibile.
Per dire, se devo aggiungere un nuovo attributo la cui necessità esca fuori durante lo sviluppo (ad esempio una colonna stipendio_mensile), in EAV basterà semplicemente aggiungere una riga (e non una colonna, come avrei dovuto fare nel primo caso); questo è un vantaggio più che altro dal punto di vista strutturale del database. Nel modello tradizionale avrei dovuto specificare un valore di default per la nuova colonna, con il problema di dover curare eventuali problemi di retrocompatibilità . Nel modello EAV, invece, sto memorizzando solo i valori che ci sono, e questo offre un notevole vantaggio se dobbiamo salvare dati con molte colonne (ad esempio per un e-commerce può convenire usare Woocommerce + WordPress se i dati dei prodotti possiedono molte colonne di attributi).
Cambiare le colonne è un’operazione che va effettuata con attenzione nel primo modello, e che spesso diventa causa di errori di ogni genere. Per come si lavora sui siti in WP, pertanto, è decisamente efficente e funzionale, per quanto non impeccabile dal punto di vista delle prestazioni.
👇 Da non perdere 👇
- 📈 Analizza Cellulari 📱
- 🔐 AI che dolor, Chat
- 🎯 Targetizza Database SQL 🗄
- 📊 Analizza Errori più comuni 📛
- 🚧 Costruisci Evergreen 📟
- 👩💻 Programma Gratis 🎉
- 💻 Configura Hosting a confronto 💑
- 🔒 Conosci Hosting reti e domini 💻
- 👩💻 Tapioca Informatica 🖥
- 💻 Iconizza Internet 💻
- 🔒 Gestisci Lavoro 🔧
- 💡 Mostra Marketing & SEO 🌪
- 🔑 Apprendi Meteo ⛅
- 🤯 Visiona Mondo Apple 🍎
- 🔍 Supervisiona Mondo Domini 🌐
- 🚀 Metti in cloud monitoraggio servizi online 📈
- 🔮 Anatomizza Nuove tecnologie 🖥
- 🔒 Antani PEC e firma digitale 📩
- 👀 Prematura Programmare 🖥
- 🎮 Lonfa Scrivere 🖋
- 🔒 Conosci Servizi di SMS 📶
- 👀 Guarda Sicurezza informatica e privacy digitale 🖥
- 🎮 Ricorda Siti web 🌎
- 🤖 Ottimizza Spiegoni 🎓
- 🧠 Neuralizza Svago 🎈
- 📡 Quantizza Usare Excel 🌀
- 🤖 Sovrascrivi Windows 😲
- 🎨 Personalizza Wireless 🚁
- 🔑 Decifra WordPress 🤵
- 💬 Il nostro canale Telegram: iscriviti
- 🟢 Guida pratica ai MOOC (Massive Open Online Course): cosa sono e dove trovarli
- 🟡 Come attivare i rich snippets in WordPress
- 🟠 Guida pratica ai MOOC (Massive Open Online Course): cosa sono e dove trovarli
