Wenns klemmt im Datenkorsett

Ich habe mich schon an anderer Stelle darüber ausgelassen, daß das Datenmodell von WordPress alles andere als relational wohlstrukturiert und insgesamt renovierungsbedürftig ist.  Wenn  man sich ein bißchen mit multifunktionalen Plugins wie z.B. woocommerce beschäftigt, stellt man immer wieder fest, daß Entitäten in die vorhandenen WordPress-Tabellen gequetscht werden, die eigentlich nicht wirklich hineinpassen. Um beim Beispiel woocommerce zu bleiben, weil das ja doch sehr verbreitet und gut dokumentiert ist: da werden die zu verkaufenden Produkte in der Tabelle wp_posts wie Beiträge angelegt, und was man hier an Produkteigenschaften und benutzerdefinierten Feldern nicht mehr untergebracht hat, landet in der wp_options, der wp_postmeta oder in der wp_terms und ihren Verwandten. Damit man hier auch alles unterbringt, obs jetzt logisch paßt oder nicht, kommt ein tolles Konstrukt zum Einsatz (übrigens nicht nur in WordPress, das gibts auch anderswo):

Serialized Data

Was ist das? Wenn sie einen Datenbankeintrag finden , der so aussieht:

a:1:{s:14:“pa_code“;a:6:{s:4:“name“;s:14:“pa_code“;s:5:“value“;s:0:““;s:8:“position“;i:0;s:10:“is_visible“;i:1;s:12:“is_variation“;i:0;s:11:“is_taxonomy“;i:1;}}

Das sind serialisierte Daten. Es handelt sich hier um ein Produktattribut namens „code“, das in dieser besonders verklausulierten Form abgelegt wurde. Wer genauer wissen möchte, was serialisierte Daten sind, kann hier im PHP-Manual mal nachlesen, und mir ganz ehrlich sagen wenn er auch nur die Hälfte verstanden hat. Soweit ich es kapiert habe, erlaubt es die Serialisierung, in einem einzigen Datenbankfeld mehrere Variable unterschiedlicher Datentypen zu speichern.  In einem Array, mit Hilfe eines Objekts. Aber, ich gebe wie gesagt ehrlich zu ich hab nicht genau verstanden, wie das wirklich funktioniert. Da schwirrt es in den Manuals nur so von Objekten und Klassen und Methoden, und mir fehlt echt die Geduld (und der Hang zur Verkomplizierung) mich da weiter einzulesen. Ich habs versucht, und bin dabei unter anderem auf einen besonderen Leckerbissen gestossen:

Eine Funktion namens maybe_serialize()

Allen Ernstes. Laut Codex macht die Folgendes: sie serialisiert Daten, falls nötig. Ich muß da unbedingt mal wörtlich zitieren:

Confusingly, strings that contain already serialized values are serialized again, resulting in a nested serialization. Other strings are unmodified.

Ach nee, „confusingly“, also verwirrenderweise? Da brat mir doch einer einen Storch! Und wie kriegt man die Daten da wieder raus? Gute Frage. Es gibt tatsächlich auch eine Funktion namens maybe_unserialize(), ist das nicht schön? Irgendwas muß man damit doch anfangen können… meine Recherchen haben aber noch nicht ergeben, was man sinnvollerweise damit macht.

Wofür soll das alles gut sein?

Der Knackpunkt ist: hier werden buntgemischte Daten in ein einziges Tabellenfeld geklemmt, statt sie sauber nach Datentypen getrennt in einer passenden Tabelle zu speichern. Damit bringt man mehr Informationen als vorgesehen in einer bereits vorhandenen Tabelle unter, aber das Auslesen und Weiterverarbeiten wird beliebig kompliziert und erstmal sehr verwirrend und umständlich. Und mal ganz im Ernst: eine Funktion, die „maybe“ irgendwas macht, die kann ich nicht gebrauchen. Das sind Stilblüten der objektorientierten Programmierung, die allem widersprechen, was ich über Datenmodellierung und Tabellenstrukturierung je gelernt habe.

Um beim Beispiel woocommerce zu bleiben: das Plugin gönnt sich ja ohnehin ein gutes Dutzend eigener Tabellen. Warum legt man dann für die Produktattribute nicht auch eine eigene Tabelle an, in der die nötigen Daten in lesbarer und vor allem auch per SQL auswertbarer Form gespeichert werden? Kostet auch nicht mehr, und wäre unendlich benutzerfreundlicher. Den Mumpitz mit den vielleicht oder auch nicht serialisierten Daten könnte man sich dann echt sparen.