Post meta vs tabelle separate del database

Se il tuo plugin dovrà gestire MOLTI dati, allora utilizzare la tabella wp_postmeta NON è una buona idea, come dimostrato di seguito:

Prendendo WooCommerce come esempio, in un negozio con circa 30.000 prodotti, ci sarà una media di, diciamo, circa 40 metadati per prodotto (attributi e tutto il resto), 5 immagini per prodotto, il che significa che ci saranno circa 4 metadati per ogni immagine:

30.000 prodotti x 40 metadati ciascuno = 1.200.000 righe in wp_postmeta

+

30.000 prodotti x 5 immagini ciascuno x 4 metadati per immagine = 600.000 righe in wp_postmeta

Quindi, con soli 30.000 prodotti, ti ritroverai con 1.800.000 righe in wp_postmeta.

Se aggiungi più proprietà ai tuoi prodotti o alle immagini dei prodotti, questo numero aumenterà.

Il problema è duplice:

• I self join sono molto costosi con MySQL
• La tabella wp_postmeta non è indicizzata a meno che non si utilizzino versioni più recenti di MySQL (ad esempio, nessun indice FULLTEXT per meta_value)

Per fare un esempio da un caso reale:

SELECT meta_value FROM wp_postmeta WHERE meta_key LIKE '_shipping_city'

Questa query, che seleziona la città di spedizione da tutti i dettagli degli ordini, impiega ben ~3 secondi su un server dedicato entry level anche se ci sono solo 5-10 ordini. Questo perché la query viene eseguita su una tabella wp_postmeta che contiene circa 3 milioni di righe in un'installazione live.

Anche la home page risulta piuttosto lenta, perché il tema recupera vari elementi da wp_postmeta - slider, alcune recensioni, alcuni altri metadati. In generale, l'elenco dei prodotti è molto lento e le ricerche sono altrettanto lente quando si elencano i prodotti.

Non puoi risolvere questo problema con mezzi normali. Potresti installare Elastic Search sul tuo server e utilizzare un plugin Elastic Search per WordPress, potresti usare redis/memcached, potresti utilizzare un buon plugin di cache per le pagine, ma alla fine il problema fondamentale rimarrà - recuperare qualsiasi quantità di dati da una tabella wp_postmeta gonfia sarà lento, ogni volta che viene fatto. Sul server dove ho testato la soluzione che ho implementato qui sotto, tutti questi strumenti erano installati, configurati e ottimizzati correttamente, e il sito funzionava accettabilmente bene per gli utenti non loggati o per le query comuni, poiché i plugin di caching entravano in azione.

Ma nel momento in cui un utente loggato cercava di fare qualcosa che non era comune o i cron, i plugin di caching o qualsiasi altra utility dovevano recuperare dati effettivi dal database per memorizzarli nella cache o fare altro, le cose diventavano lentissime.

Quindi ho provato qualcos'altro:

Ho codificato un piccolo plugin per spostare tutti i metadati dei prodotti (postmeta per il post type product) in una tabella personalizzata generata dal codice. Questo plugin ha preso tutti i metadati per ogni post e ha creato una tabella aggiungendo ogni metadato come colonna e inserendo i valori in ogni riga. Ho trasformato il formato EAV in un formato relazionale piatto e orizzontale. Ho anche fatto in modo che il plugin eliminasse i postmeta dai prodotti spostati dalla tabella wp_postmeta.

Approfittandone, ho spostato anche i metadati degli allegati e i metadati di tutti gli altri post type nelle loro tabelle personalizzate.

Poi ho agganciato il filtro get_(post_type)_meta per sovrascrivere il recupero dei metadati e servirlo dalle nuove tabelle personalizzate.

Ora la stessa query di prima, che impiegava ~3 secondi per essere eseguita su wp_postmeta, impiega ~0,006 secondi. Il sito ora si comporta come se fosse una nuova installazione di WP.

....................

Naturalmente, fare le cose alla maniera di WordPress è meglio. È effettivamente la norma.

Tuttavia, è anche ovvio che una tabella EAV è molto inefficiente in termini di scalabilità. È infinitamente flessibile e ti permette di memorizzare qualsiasi dato, ma il prezzo che paghi per questo è la performance. È un compromesso fondamentale.

In questo contesto, è difficile dire a qualcuno che intende avere una montagna di dati e - Dio non voglia - eseguire query/ricerche su quei dati di utilizzare sicuramente la tabella wp_postmeta. Il calo di prestazioni sarà notevole.

L'uso di tabelle personalizzate ti permetterà di accumulare dati e mantenerli comunque abbastanza veloci.

Proprio come Pippin Williams, il creatore del plugin Easy Digital Downloads, ha detto che userebbe tabelle personalizzate se iniziasse oggi a codificare il suo plugin, se hai intenzione di creare qualcosa che verrà utilizzato a lungo o che accumulerà molti dati, è più efficiente utilizzare tabelle personalizzate se le progetti bene.

Devi assicurarti che qualsiasi altro sviluppatore di plugin/addon abbia i mezzi per agganciarsi al tuo plugin e manipolare i tuoi dati prima e dopo il recupero. Se lo fai, allora sei a posto.

Dipende da ciò che stai facendo. Il modo corretto in WordPress è utilizzare le tabelle esistenti, poiché sono state progettate per essere abbastanza flessibili. Tuttavia, occasionalmente potresti incontrare una nuova classe di dati che non può essere inserita in una tabella esistente, ad esempio se volessi memorizzare metadati per le categorie, potresti scegliere di creare una tabella wp_termsmeta.

Tuttavia, solitamente puoi memorizzare i tuoi dati comodamente nelle diverse tabelle esistenti, e dove archiviarli dipende da ciò che fa il tuo plugin.

• Per impostazioni generali del plugin, utilizza la chiamata API get_option() - verrà anche memorizzata nella cache.
• Per impostazioni del plugin specifiche per un singolo articolo, utilizza i metadati personalizzati per articolo con get_post_meta(). Di solito è più che sufficiente per ciò che ti serve.

WordPress implementa anche un sistema di caching per velocizzare i tempi di risposta.

concordo al 100% con Denis. Ma c'è un modo per aggirare il problema.

Il problema nell'usare i post meta per valori da interrogare si presenta quando i valori sono array, ecc. Come in questo esempio:

array(
'key1' => 'val 1',
'key2' => 'val 2'
);

Questo viene memorizzato nel database come una stringa serializzata, che apparirà più o meno così:

{array["key1"]...{}...}

Quindi, quando vuoi interrogare tutti i post con array['key2'] = 'val 2', WordPress deve estrarre ogni meta entry chiamata array, decomprimerla, testarla e poi passare alla successiva. Questo farà sicuramente crollare il tuo server se il tuo sito ha successo e contiene molti post, pagine, custom post, ecc.

La soluzione dipende dal progetto, e capirai perché. Se memorizzi i dati come var = val, WordPress sarà in grado di cercare senza che PHP debba decomprimere ogni singolo test. Per farlo nello scenario precedente, useresti alcuni namespace e memorizzeresti le meta key:

_array_key1 = 'val 1';
_array_key2 = 'val 2';

quindi WordPress cercando la key 2 con val 2 sarà in grado di estrarla direttamente. Tuttavia, questo dipende dal progetto. Il mio progetto attuale si basa su circa 20 diversi tipi di dati da memorizzare con ogni custom post, quindi quanto sopra creerebbe semplicemente una tabella enorme da cercare, visto che ci aspettiamo centinaia di migliaia di post. Quindi in quello scenario una tabella personalizzata è l'unica soluzione.

Spero che questo possa aiutare qualcuno

Per il mio sito su FarmVille :) Ho fatto entrambe le cose ma non l'ho mai completato perché l'ho venduto:

1. Ho letto l'XML di FarmVille e ho scaricato i dati in una tabella personalizzata
2. In WordPress avevo creato campi personalizzati automaticamente per ogni campo in quella tabella (e alcuni extra)
3. Ora il problema è cosa succede se un valore cambia nella tabella o dall'altra parte: i campi personalizzati devono rimanere continuamente sincronizzati

Ho fatto questo perché volevo che da un lato gli utenti potessero modificare il sito WordPress inserendo nuovi dati di FarmVille, ad esempio "una mucca costa 10 monete" MA dall'altro lato dell'integrazione: SE un cambiamento nell'XML significava che la mucca ora costa "20 monete" (tramite il plugin di modifica front-end), questo sarebbe stato dato come opzione dopo: in modo che o l'XML O l'utente avesse ragione (una sorta di sistema wiki).

Quindi ecco un esempio quando si usano entrambi.