nicht angemeldet
Hi,
Und vorrausgesetzt, er will das Menü später _nicht_ wieder herstellen, wäre er doch gar besser bedient, es nicht zu serialisieren, weil er besser in den abgelegten Daten suchen kann.
Wie ich zu Beginn schrieb, ist die Verwendung abhängig davon, wie er die Daten weiterverarbeiten will. Will er sie mit PHP weiter nutzen, dann ist serialize besser geeignet, da serialize eine Umkehrfunktion hat und print_r nicht.
Was das Suchen angeht, ist die Frage, wie er suchen will. Mit MySQL liegen die Daten in beiden Varianten als String vor, sind also gleich gut durchsuchbar.
Einige Suchanfragen ("gib mit das Menuitem innerhalb des Menus "Main", welches den Namen "Bla" trägt und den Schlüssel 5 hat") kann man nur beantworten, wenn man die Datenstuktur in ihrer Struktur versteht, da reicht eine Textsuche nicht mehr. Und dann ist serialize klar überlegen.
Und nochmals: ich habe genau einen (!) Fall gehabt, wo ich mal mit serialize in der Datenbank etwas abgelegt habe. Da habe ich aber auch eine bewusste Abkürzung genommen, um bestehenden Code möglichst wenig anpassen zu müssen (ich wollte einen bestehenden Job "queuen", d.h. zeitversetzt abarbeiten. Die Jobdaten habe ich in ihrem "Jobobjekt", in diesem Fall ein Mail-Objekt, als serialisierten String in der DB gespeichert und die Queue-Tabelle per cronjob abgearbeitet). Ansonsten empfiehlt es sich eigentlich immer, die Datenstruktur ordentlich in ein Schema einzupassen.
Etwas anderes wäre es, wenn man die Datenstuktur für einen Transport serialisieren muss. Hier ist serialize auch print_r überlegen (wenn man nur PHP-clients auf der Gegenseite hat), trotzdem würde ich sprachneutral eher zu JSON oder gar XML tendieren (weil es mir die Möglichkeit offenhält, auf der Gegenseite einen Client in nicht-PHP zu schreiben; der Output von serialize ist zwar auch in anderen Sprachen parsebar, aber ich kenne keine fertige Library, wie sie z.B. JSON für diverse Sprachen anbietet).
Ob jetzt print_r oder serialisize eine höhere Serverauslastung verursacht, weiß ich allerdings nicht.
Ich denke, der Unterschied ist vernachlässigbar. Darauf eine Entscheidung aufzubauen wäre premature optimization.
Bis die Tage,
Matti
Der Martin