it-swarm.com.de

Soll ich benutzerdefinierte Post-Typen oder benutzerdefinierte Datenbanktabellen für die Plugin-Entwicklung verwenden?

Ich bin ziemlich neu darin, WordPress-Plugins zu schreiben, aber ich bin bereits in die Tiefe gesprungen und möchte sicherstellen, dass ich es bei meinem bevorstehenden großen Projekt "richtig" mache.

Ich werde WordPress stark zu einer ziemlich großen Web-App ausbauen und möchte meine Datenstrukturen so nativ wie möglich halten, um mich auf das WordPress-Framework zu verlassen, aber ich weiß nicht, ob es besser ist, meine eigenen benutzerdefinierten Datenbanktabellen zu erstellen oder versuchen Sie, benutzerdefinierte Beitragstypen zu verwenden.

Ich kenne noch nicht alle meine Daten, aber es wird eine Reihe von Tabellen (oder Cpts) geben, die relational verknüpft sind. Aus meinen Recherchen geht hervor, dass ich benutzerdefinierte Datenbanktabellen vermeiden sollte, aber ich bin nicht sicher, wie ich die beste Lösung ermitteln soll.

Konkret geht es mir um drei Bereiche:

  • die Anzahl der Post-Metafelder, die ich für meine zusätzlichen Felder pro Punkt benötige, wenn ich diese Route gehe, und wenn das die Dinge "knifflig" macht
  • wie gut kann ich Abfragen mit halbkomplexen relationalen Filtern für Berichte zurückerhalten?
  • wie man Beziehungen am besten verwaltet, besonders wenn ich viele bis viele Beziehungen habe

Gibt es einen "richtigen" Weg? Danke für deinen Beitrag.

37
Jeff

Sie sollten jedem gegenüber skeptisch sein, der sagt, dass es einen einzigen "richtigen" Weg gibt. Der richtige Weg hängt von der jeweiligen Situation ab. Die Nutzung der CPT-Infrastruktur bietet eine Reihe bemerkenswerter Vorteile:

  • Sie erhalten die Dashboard-Benutzeroberfläche kostenlos
  • Sie nutzen automatisch das Caching von WP, einschließlich der von der Installation möglicherweise verwendeten Plugins für dauerhaften Cache
  • Sie erhalten automatisch Goodies wie Post-Revisionen
  • Sie erhalten Zugriff auf die Klasse WP_Query, was bedeutet, dass Sie theoretisch kein (oder zumindest nicht viel) wahrscheinlich fehlerhaftes und anfälliges und ineffizientes SQL schreiben müssen
  • Wenn Sie das Plugin verteilen oder für die Open-Source-Entwicklung öffnen möchten, sind Entwickler möglicherweise mit benutzerdefinierten Beitragstypen und den zugehörigen API-Funktionen zufriedener als mit Ihren eigenen benutzerdefinierten Inhalten

Die Probleme mit der CPT-API resultieren hauptsächlich aus der Tatsache, dass sie in hohem Maße mit der Metapher von "Posts" und allen Aspekten dieses Datentyps verheiratet ist, die mit der Metapher einhergehen. Führen Sie in der MySQL-Befehlszeile DESCRIBE wp_posts aus. WP setzt voraus, dass Ihr Inhalt einen Titel hat, dass er einen (einzelnen) Autor hat, dass Sie nur das Erstellungsdatum und das Datum der letzten Bearbeitung verfolgen müssen, dass Sie Platz für eine benötigen nicht indizierter post_content usw. Dies funktioniert gut für einige Arten von Inhalten, aber nicht unbedingt für andere. Sie haben bereits auf einige mögliche Probleme hingewiesen:

die Anzahl der Post-Metafelder, die ich für meine zusätzlichen Felder pro Punkt benötige, wenn ich diese Route gehe, und wenn das die Dinge "knifflig" macht

Es gibt zwei Möglichkeiten, das wp_posts-Schema über die CPT-API zu erweitern: Postmeta und Taxonomien. Postmeta ist ein nicht indiziertes Schlüssel-Wert-Paar, das sich hervorragend zum Speichern einer Reihe verschiedener Daten eignet, jedoch überhaupt nicht für komplexe Suchvorgänge optimiert ist. Taxonomien sind in dieser Hinsicht etwas flexibler, aber Sie werden immer noch mit vielen potenziell kostspieligen Unterabfragen konfrontiert, wenn Sie über sehr komplexe Suchvorgänge verfügen. (Die Argumente meta_query und tax_query und ihre Abfragekonstruktorklassen sind jedoch sehr schön und praktisch.)

Wenn Sie, wie Sie vorschlagen, nur diese Art von "halbkomplexen relationalen Filtern" für gelegentliche Berichte ausführen müssen, ist diese Architektur wahrscheinlich für Sie in Ordnung. Wenn Sie damit beginnen, die Filter für Benutzer verfügbar zu machen, müssen Sie ständig viele komplexe JOINs und Unterabfragen ausführen, damit die Dinge schnell außer Kontrolle geraten.

wie man Beziehungen am besten verwaltet, besonders wenn ich viele bis viele Beziehungen habe

Viele-zu-viele-Beziehungen sind ein langjähriger Knackpunkt in der WP dev-Community (siehe https://core.trac.wordpress.org/ticket/14513 ). Sie können es fälschen, ohne benutzerdefinierte Tabellen zu verwenden, indem Sie Taxonomieelemente auf post_ids mappen (sodass Sie beispielsweise sagen können, dass P3 die Beziehung Y zu P5 hat, indem Sie sagen, dass P3 das Tag Y-P3 hat), was jedoch verwirrend wird (und ineffizient) sehr schnell. Möglicherweise können Sie auch eine eigene Beziehungstabelle erstellen, die CPTs miteinander verknüpft. Sie können jedoch weiterhin die Vorteile von CPTs nutzen und nur eine einzelne DB-Tabelle erstellen. Eine gut ausgeführte Version dieser Methode finden Sie im Plugin "Posts 2 Posts": https://wordpress.org/extend/plugins/posts-to-posts/

Am Ende sollten Sie sich also für Folgendes entscheiden:

  • Die Art (en) der Daten, die Sie speichern - wie "posten" sie sind
  • Welche Art von Abfragen erforderlich sind - wie komplex werden sie sein?
  • Skalieren - wie komplex ist Ihr gewünschtes Schema, wie viele Objekte werden Sie insgesamt haben und wie viele Benutzer erwarten Sie

Wenn die Antworten lauten: Sehr postiv, nicht zu komplex und nicht übergroß skalierbar, entscheiden Sie sich für CPTs. Ansonsten betrachten Sie Ihre eigenen Tabellen.

56
Boone Gorges