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

Ich bin noch 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 in eine ziemlich große Web-App erweitern 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 diesen Weg 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.

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 können das Caching von WP automatisch nutzen, einschließlich aller persistenten Cache-Plugins, die die Installation möglicherweise verwendet
• Sie erhalten automatisch Goodies wie Post-Revisionen
• Sie erhalten Zugriff auf die WP_QueryKlasse, 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 aus DESCRIBE wp_posts. WP geht davon aus, 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 einen nicht indizierten benötigen post_contentusw. Dies funktioniert gut für einige Arten von Inhalten, aber nicht unbedingt für andere. Sie haben bereits auf mögliche Probleme hingewiesen:

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

Es gibt zwei Möglichkeiten, das wp_postsSchema ü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 meta_queryund tax_queryArgumente und ihre Frage- Konstruktions Klassen sind sehr schön und praktisch, though.)

Wenn, wie Sie vorschlagen, Sie nur brauchen diese Art von „semi komplexen relationalen Filter“ im Fall von gelegentlichen Berichten zu tun, dann ist diese Architektur wahrscheinlich OK für Sie. Wenn Sie anfangen, die Filter für Benutzer JOINverfügbar zu machen, so dass Sie ständig viele komplexe s und Unterabfragen ausführen müssen, geraten die Dinge schnell außer Kontrolle.

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-Entwickler-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 profitieren weiterhin von CPTs und erstellen nur eine einzige DB-Tabelle. Eine gut ausgeführte Version dieser Methode finden Sie im Posts 2 Posts-Plugin: 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 sein werden - 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.