MySQL läßt sich so schön übersetzen
Mir gefällt auch die Semantik: das ist „Mein SQL“, hier kann ich schalten und walten wie ich will, kann Tabellen und Abfragen anlegen und verknüpfen, kann sortieren und inserten und updaten nach Lust und Laune, und Open Source und kostenlos ist es obendrein. MySQL bietet wirklich unbegrenzte Möglichkeiten und ist flexibel ohne Ende. Über den genialen phpMyAdmin steht auch eine professionelle Verwaltungsoberfläche zur Verfügung, die keine Wünsche offenläßt. Also, warum nutzen wir dann dieses Potential nicht zur Erweiterung von WordPress?
Ist es unanständig, eigene Tabellen zu benutzen?
Wenn ich mir viele Plugins und WordPress-Erweiterungen so anschaue, drängt sich mir immer der Gedanke auf: da wäre Vieles mit eigenen Tabellen eleganter gelöst. Da wird die wp_posts hergewürgt um Bilder für eine Slideshow zu verwalten, da klingelt es nur so in der wp_postmeta vor lauter benutzerdefinierten Feldern, da werden wp_terms und Konsorten zur Erzeugung eigener Taxonomien gebeutelt – hallo, das geht auch viel einfacher!
Aber anscheinend gehört es nicht zum guten Ton und ist nicht heilige „Best Practice“, WordPress mit eigenen Tabellen zu erweitern. Dabei ist die existierende Tabellenstruktur uralt und hat definitiv auch einige Design Flaws – ich erinnere nur an die gemischte Verwaltung von Bildern und Beiträgen in der wp_posts, da werden grundverschiedene Entitäten zusammengeschmissen, die eigentlich nichts miteinander zu tun haben. Statt die alte Tabellenstruktur mal zu überarbeiten und aufzufrischen, sind aber heute Legionen von Programmierern damit beschäftigt, neue Logiken in die alte „eiserne Jungfrau“ von einer Architektur zu quetschen, und möglichst bloß nicht ogottogott neue Tabellen anzulegen und einzubinden. Warum das so ist? Keine Ahnung, ich beobachte diese Tendenz nur immer wieder und wundere mich.
Mir ist das Wurst: ich nehme eigene Tabellen wo es praktisch ist
Wie ich vorher schon angesprochen habe: in jedem noch so kleinen Laden gibt es immer Listen, Artikelstammdaten etwa, Kundenadressen mit Kundennummern, Mitgliederverzeichnisse und so weiter und so fort… Ob diese Listen jetzt in Excel, Access oder MySQL geführt werden, ob ein professionelles CRM/ERP System wie Wiso MeinBüro oder Lexware oder anderes eingesetzt wird, die Listen sind da, und wir wollen unsere Stammdaten auch in WordPress nutzen. Statt sie jetzt umständlich in benutzerdefinierte Felder einzuhacken, gibt es auch einen einfacheren Weg.
Der Schlüssel: ja eben!
Der Schlüssel zu dem ganzen Zauber ist: der Schlüssel, auch Kennziffer oder (meistens) ID genannt. Jeder noch so kleine Kaufladen hat Artikelnummern, jeder Verein hat Mitgliedsnummern, jede Kanzlei hat Mandantennummern – der Witz ist, daß jede Entität (jeder Artikel, jeder Kunde, jedes Mitglied) durch eine eindeutige Nummer identifizierbar ist. Wo Datenbanken verwendet werden, ist es üblich einen numerischen Schlüssel durch ein AutoIncrement-Feld automatisch vergeben zu lassen. Es gibt aber auch alphanumerische Schlüssel, z.B. Artikelnummern nach einem Muster wie DE-1234. EN-1234, wo DE bzw. EN dann logischerweise für Deutsch oder Englisch steht. Soweit alles logo?
Ja, dann verwenden wir sie halt auch, die Schlüssel! Wenn wir schon einen eindeutigen Identifikator für unsere Datensätze haben, dann nehmen wir den auch her, um die Verknüpfung zu unserem guten alten WordPress herzustellen. Damit es nicht ganz so trocken wird, nehme ich mal ein anschauliches Beispiel, an dem man gut sehen kann, was sich mit eigenen Tabellen in WordPress so alles leicht realisieren läßt. Aber dazu gibt es einen neuen Beitrag.