Se voglio salvare le impostazioni per il mio plugin, è abbastanza semplice e diretto.
Ora vorrei salvare un po 'di più nel database.
Un nome file e altri 3 valori che si applicano solo a quel file. E ci sono molti file con quei valori. È possibile salvare il tipo di sottoarray utilizzando metodi di database integrati? Come posso eliminarli e ordinarli ecc.?
Risposte:
Raramente non sono d'accordo con utenti altrimenti informati, ma in questo caso non posso farne a meno. A mio avviso, chiamare l'uso di tabelle di database non core è una cattiva pratica di per sé è semplicemente sbagliato.
La scelta se scegliere le tabelle principali o aggiungere le proprie dipende da diversi fattori.
Il tempo di esecuzione di una query dipende dalla dimensione della tabella. Quindi, se stai pianificando di archiviare quantità significative di dati, una tabella separata che si rivolge solo a questo tipo di set di dati specifici sarà inevitabilmente la soluzione più efficiente.
Se si memorizza un sacco di post regolari o CPT accanto a questi insiemi di dati specifici, wp_postscosì come wp_postmetapuò crescere rapidamente.
Per me, questa scelta dipende in definitiva da quanto "postino" i dati. Dovrebbe supportare un autore, commenti, revisioni, estratti o simili? Se è così, andrò con CPT e / o funzionalità di base. In caso contrario, andrò con tabelle separate per motivi di utilizzo delle risorse ed efficienza.
Se l'idea di Eugene fosse corretta, nessuno dei plugin ben scritti esistenti aggiungerebbe le proprie tabelle, cosa che per fortuna non è il caso.
$wpdbclasse molto potente .wp_optionse costringendo lo sviluppatore del plug-in a considerare attentamente il tipo di dati creati / archiviati: è un CPT? è una tassonomia? è post meta?Tuttavia, per quei casi di utilizzo in cui è necessaria una tabella DB separata, assicurati di utilizzare il metodo fornito da WordPress per aggiungere la tua tabella personalizzata al database WordPress , in particolare per sfruttare la potente $wpdbclasse. Nota le informazioni / avvertenze di questo elenco di voci del codice:
Informazioni sulla configurazione : le scelte dell'utente che vengono immesse quando l'utente imposta il plug-in per la prima volta e che non tendono a crescere oltre (ad esempio, in un plug-in relativo ai tag, le scelte dell'utente relative al formato del cloud di tag in la barra laterale). Le informazioni di installazione verranno generalmente archiviate utilizzando il meccanismo delle opzioni di WordPress.
Dati : informazioni aggiunte mentre l'utente continua a utilizzare il plug-in, che in genere sono informazioni espanse relative a post, categorie, caricamenti e altri componenti di WordPress (ad esempio, in un plug-in relativo alle statistiche, le varie visualizzazioni di pagina, i referrer e altre statistiche associate a ciascun post sul tuo sito). I dati possono essere memorizzati in una tabella MySQL separata, che dovrà essere creata. Prima di entrare in una tabella completamente nuova, tuttavia, considera se la memorizzazione dei dati del tuo plugin in Post Meta (aka campi personalizzati) di WordPress funzionerebbe. Post Meta è il metodo preferito; usalo quando possibile / pratico.
Pertanto, possiamo concludere quanto segue:
$wpdb(usarlo con i tavoli non core era implicito nella mia risposta, non avrei voluto perdere quella classe)
Le tabelle di database non core sono indispensabili se i tuoi dati sono più complessi del modello di post di WordPress, saranno enormi e avranno molti meta dettagli che verranno cercati.
Il formato EAV che WordPress utilizza per il suo meta meta non si presta bene alla ricerca multi-criterio.
Se dividi il tuo meta in molte voci, avrai numerose voci per post nella meta table post e la ricerca di qualsiasi post attraverso metas sarà molto più lenta.
Se memorizzi tutti i metas serializzati in un array e lo hai come una sola voce nel post meta, questa volta sarai costretto a fare solo ricerche di testo all'interno di quel meta e non sarai in grado di usare gli operatori di confronto direttamente nella tua query sql.
Non è un grosso problema se il tuo plugin non avrà migliaia di voci e meta associati.
Ma un grosso problema se il tuo plugin farà qualcosa di grande.
La tua situazione, un nome file come voce indipendente e 3 voci metadati associate a quella voce non sembrano così grandi. È possibile utilizzare la tabella post wordpress e la meta table per questo.
MA, se le persone cercheranno spesso questi 3 metas, SOPRATTUTTO congiuntamente, consiglierei di impostare tabelle separate.
Con quel formato solo una tabella con una sola voce, che contiene anche tutti i metas, sarebbe ok e interrogherebbe alla velocità della luce.
Per inciso, se si utilizzano le tabelle di WordPress e si utilizza anche la memorizzazione nella cache delle query, l'utente cerca i propri dati che verrebbero memorizzati nella cache nel tempo e subirebbero un minor carico. Ma questo non sarebbe così prudente come fare tavoli separati.
Puoi caricare i tuoi file nella libreria multimediale. Ogni elemento nella libreria multimediale è memorizzato nella wp_poststabella. Significa che ogni file può avere metadati. Puoi salvare tutte le informazioni di cui hai bisogno per ogni file nella wp_postmetatabella usando l' API Metadata .
È una cattiva pratica creare la propria tabella per un plugin?
Sì, è una cattiva pratica creare la propria tabella, se invece è possibile utilizzare la funzionalità principale.
class TMM {
public static $options;
public static function register() {
self::$options = get_option(TMM_THEME_PREFIX . 'theme_options');
}
public static function get_option($option) {
return @self::$options[$option];
}
public static function update_option($option, $data) {
self::$options[$option] = $data;
update_option($prefix . 'theme_options', self::$options);
}
//ajax
public static function change_options() {
$action_type = $_REQUEST['type'];
$data = array();
parse_str($_REQUEST['values'], $data);
$data = self::db_quotes_shield($data);
if (!empty($data)) {
foreach ($data as $option => $newvalue) {
if (is_array($newvalue)) {
self::update_option($option, $newvalue);
} else {
$newvalue = stripcslashes($newvalue);
$newvalue = str_replace('\"', '"', $newvalue);
$newvalue = str_replace("\'", "'", $newvalue);
self::update_option($option, $newvalue);
}
}
}
_e('Options have been updated.', TMM_THEME_FOLDER_NAME);
exit;
}
public static function db_quotes_shield($data) {
if (is_array($data)) {
foreach ($data as $key => $value) {
if (is_array($value)) {
$data[$key] = self::db_quotes_shield($value);
} else {
$value = stripslashes($value);
$value = str_replace('\"', '"', $value);
$value = str_replace("\'", "'", $value);
$data[$key] = $value;
}
}
}
return $data;
}
}