Ist es eine schlechte Übung, eine eigene Tabelle für ein Plugin zu erstellen?

Wenn ich Einstellungen für mein Plugin speichern möchte, ist das ziemlich einfach und unkompliziert.

Jetzt möchte ich etwas mehr in die database speichern.

Ein Dateiname und drei weitere Werte, die nur für diese Datei gelten. Und es gibt viele Dateien mit diesen Werten. Ist es möglich, eine Art von Subarrays mit eingebauten databasemethoden zu speichern? Wie kann ich sie löschen usw.?

Solutions Collecting From Web of "Ist es eine schlechte Übung, eine eigene Tabelle für ein Plugin zu erstellen?"

Ich stimme kaum mit ansonsten sachkundigen Benutzern überein, aber in diesem Fall kann ich nicht helfen. Meiner Meinung nach ist die Verwendung von Nicht-core-databasetabellen schlechte Praxis per se einfach falsch.

Die Entscheidung, ob Sie coretabellen verwenden oder eigene hinzufügen möchten, hängt von mehreren Faktoren ab.

Die Ausführungszeit einer Abfrage hängt von der Größe der Tabelle ab. Wenn Sie also große Datenmengen speichern möchten, ist eine separate Tabelle, die sich nur auf diesen einen spezifischen Datensatz bezieht, zwangsläufig die effizientere Lösung.

Wenn Sie neben diesen spezifischen Datensätzen viele regelmäßige Posts oder CPTs speichern, können sowohl wp_posts als auch wp_postmeta schnell wachsen.

Für mich hängt diese Wahl letztendlich davon ab, wie “posty” die Daten sind. Sollte es einen Autor, Kommentare, Revisionen, Auszüge oder ähnliches unterstützen? Wenn ja, werde ich mit CPTs und / oder corefunktionen gehen. Wenn nicht, gehe ich mit separaten Tabellen aus Gründen der Ressourcennutzung und Effizienz.

Wenn Eugenes Vorstellung richtig wäre, würde keines der vorhandenen gut geschriebenen Plugins ihre eigenen Tabellen hinzufügen, was glücklicherweise nicht der Fall ist.

Die Verwendung von WP-Core-DB-Tabellen ist die beste Vorgehensweise

  1. Die Verwendung von Core-DB-Tabellen macht Ihre Daten portabler und einfacher zu sichern, da sie sowohl vom Core-Export- / Importprogramm als auch von den Myriade Backup-Plugins gehandhabt werden
  2. Durch die Verwendung zentraler DB-Tabellen können Sie Ihre Daten einfacher und sicherer manipulieren , da Sie einen intuitiveren Zugriff auf die verschiedenen WordPress-corefunktionen zum Abfragen, Hinzufügen, Ändern, Löschen und Bereinigen von DB-Daten haben, insbesondere über die sehr mächtige $wpdb class .
  3. Die Verwendung von zentralen DB-Tabellen fördert / erleichtert Best Practices für die Datenklassifizierung und -speicherung , z. B. das Speichern von Plugin-Optionen als Array in einer einzelnen Zeile in wp_options und das wp_options des Plugin-Entwicklers, den Typ der zu erstellenden / gespeicherten Daten sorgfältig zu prüfen ein CPT? Ist es eine Taxonomie? ist es post meta?
  4. Es ist weniger wahrscheinlich, dass Ihr Plugin bei der Verwendung von Core-DB-Tabellen zurückbleibt .

WordPress bietet Plugins die Möglichkeit, Tabellen zu ihrer database hinzuzufügen

Für diese Anwendungsfälle, in denen eine separate DB-Tabelle benötigt wird, sollten Sie jedoch die WordPress-Methode zum Hinzufügen Ihrer benutzerdefinierten Tabelle zur WordPress-database verwenden , insbesondere, damit Sie die mächtige $wpdb class nutzen können. Beachten Sie die Informationen / Vorbehalte, die in diesem Codex-Eintrag aufgeführt sind:

  • Setup-Informationen – Benutzeroptionen, die eingegeben werden, wenn der Benutzer das Plug-in zum ersten Mal einrichtet , und nicht dazu neigen, weit darüber hinauszuwachsen (z. B. in einem tagbezogenen Plug-in die Auswahl des Benutzers bezüglich des Formats der Tag-Cloud) die Seitenleiste). Setup-Informationen werden in der Regel mit dem WordPress-Optionen-Mechanismus gespeichert.

  • Daten – Informationen, die hinzugefügt werden, wenn der Nutzer weiterhin Ihr Plug-in verwendet. Dies sind im Allgemeinen erweiterte Informationen zu Posts, Kategorien, Uploads und anderen WordPress-Komponenten (z. B. in einem statistikbezogenen Plug-in, den verschiedenen Seitenaufrufen, Referrern) und andere Statistiken zu jedem Beitrag auf Ihrer Website). Daten können in einer separaten MySQL-Tabelle gespeichert werden, die erstellt werden muss. Bevor Sie jedoch mit einer ganz neuen Tabelle springen, sollten Sie überlegen, ob die Daten Ihres Plugins in WordPress ‘Post Meta (aka Custom Fields) gespeichert werden. Post Meta ist die bevorzugte Methode; Verwenden Sie es, wenn möglich / praktisch.

Somit können wir folgendes feststellen:

  1. Das Speichern von Daten (Setup oder benutzergeneriert) in WP-coretabellen ist die beste Vorgehensweise
  2. Es gibt gültige Anwendungsfälle zum Erstellen von benutzerdefinierten DB-Tabellen. Daher kann das Erstellen von benutzerdefinierten DB-Tabellen nicht als eine inhärente schlechte Praxis betrachtet werden
  3. Beim Erstellen von benutzerdefinierten DB-Tabellen bietet WordPress eine Best-Practice-Implementierung

Nicht-core-databasetabellen sind ein Muss, wenn Ihre Daten komplexer als WordPress Post-Modell sind, wird es riesig sein, und es hat eine Menge von Meta-Details, die durchsucht werden.

Das EAV-Format, das WordPress für sein Post-Meta verwendet, eignet sich nicht gut für die Suche nach mehreren Kriterien.

Wenn Sie Ihr Meta in viele Einträge unterteilen, haben Sie zahlreiche Einträge pro Post in der Post-Meta-Tabelle, und die Suche in einem Post über Metas wird viel langsamer sein.

Wenn Sie alle metas serialisiert in einem Array speichern und es als nur einen Eintrag in post meta haben, werden Sie dieses Mal gezwungen sein, nur Textsuchen innerhalb dieses Metas durchzuführen, und Sie können Vergleichsoperatoren nicht direkt in Ihrer SQL-Abfrage verwenden.

Kein großes Problem, wenn Ihr Plugin nicht Tausende von Einträgen und dazugehörigem Meta haben wird.

Aber ein großes Problem, wenn dein Plugin etwas Großes machen wird.


Ihre Situation, ein Dateiname als unabhängiger Eintrag und 3 Metadateneinträge zu diesem Eintrag scheinen nicht so groß zu sein. Sie können dafür die WordPress-Tabelle und Meta-Tabelle verwenden.

ABER, wenn Leute nach diesen 3 Metas viel suchen, BESONDERS in Verbindung, dann würde ich empfehlen, dass Sie getrennte Tabellen aufstellen.

Mit diesem Format wäre nur eine Tabelle mit nur einem Eintrag, der auch alle Metas enthält, in Ordnung und würde blitzschnell abfragen.

Übrigens, wenn Sie WordPress-Tabellen verwenden und auch Query-Caching verwenden, sucht der Benutzer nach Ihren Daten, die im Laufe der Zeit zwischengespeichert werden und weniger belastet werden. Aber das wäre nicht so umsichtig wie separate Tabellen.

Sie können Ihre Dateien in die Medienbibliothek hochladen. Jedes Element in der Medienbibliothek wird in der Tabelle wp_posts gespeichert. Es bedeutet, dass jede Datei Metadaten haben kann. Sie können so viele Informationen speichern, wie Sie für jede Datei in der wp_postmeta Tabelle wp_postmeta , indem Sie die Metadaten-API verwenden .

Ist es eine schlechte Übung, eine eigene Tabelle für ein Plugin zu erstellen?

Ja, es ist eine schlechte Übung, eine eigene Tabelle zu erstellen, wenn Sie stattdessen die corefunktionalität verwenden können.

 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; } } 

  • Der Name der class ist original. Benenne ihn wie du willst.
  • In functionen php add: add_action (‘init’, Array (‘TMM’, ‘register’), 1);
  • Und füge für ajax hinzu: add_action (‘wp_ajax_change_options’, array (‘TMM’, ‘change_options’));
  • Um die Option zu erhalten, die Sie benötigen, verwenden Sie diese (zum Beispiel): $ logo_img = TMM :: get_option (‘logo_img’);
  • Verwenden Sie es, um Ihre Optionen mit nativen WordPress-Methoden zu speichern