Tach!
Aber wenn er diese verschachtelte Menüstruktur doch in $_POST verpackt hat, ist es dann nicht Wurscht, ob er $_POST über print_r zu einem String macht, den er in der DB ablegt oder über serialisize?
print_r() erzeugt eine Ausgabe zu Debug-Zwecken und es geht auch die Typ-Information verloren. Daraus lässt sich schlecht wieder das Original herstellen. Serialisieren ist ein auf Umkehrbarkeit ausgelegter Vorgang. Das Ergebnis ist zwar im Gegensatz zur print_r-Ausgabe nicht (besonders gut) menschenlesbar, geht aber mit unserialize() ebenso einfach wieder in die verarbeitbare Struktur zurückzuwandeln.
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.
Das Suchen in den beiden Formen geht ungefähr gleich gut, beziehungsweise schlecht. Strings bleiben lesbar, nur die Füllzeichen sind andere, und die stören mitunter beim Finden. Egal was für eine Datenstruktur er in seinem $_POST stehen hat, print_r ist vom Prinzip her eine Einbahnstraße und deshalb vermutlich nicht die beste Lösung für seine wie auch immer geartete Aufgabenstellung.
Ob jetzt print_r oder serialisize eine höhere Serverauslastung verursacht, weiß ich allerdings nicht.
Das ist unerheblich. Die Unterschiede machen das Kraut nicht fett.
Vielleicht zum besseren Verständnis ein Beispiel:
$x = array(
'foo' => 'bar[]',
'bla' => false,
'qux' => true,
'numbers' => array(23, 42));
print_r() erzeugt diese Ausgabe:
Array
(
[foo] => bar[]
[bla] =>
[qux] => 1
[numbers] => Array
(
[0] => 23
[1] => 42
)
)
und serialisiert sieht das so aus:
a:4:{s:3:"foo";s:5:"bar[]";s:3:"bla";b:0;s:3:"qux";b:1;s:7:"numbers";a:2:{i:0;i:23;i:1;i:42;}}
Es ist bei print_r() zu sehen, dass die eckigen Klammern bei bar[] sich nicht wirklich von denen der Keys unterscheiden. Aber das bekommt man mit einem Parser geregelt. Interessanter ist, dass false und true abhandengekommen sind. In der serialisierten Form sind sie erkennbar: b:0 und b:1
dedlfix.