it-swarm.com.de

Warum wählt WordPress die Datenserialisierung anstelle von json_encode?

In meinem kleinen Alter mit WordPress habe ich gesehen, dass WordPress selbst und seine benutzerfreundlichen Plugins in vielen Fällen PHP serialize() zum Speichern von Daten in db verwenden. Bei einer kürzlich durchgeführten Suche fand ich jedoch eine ernsthafte Unterstützung der Community für die json_encode() gegenüber der serialize().

Und ich persönlich habe mit beiden ein assoziatives Array getestet, das Folgendes zeigt:

  • serialize() speichert 342 Zeichen
  • json_encode() speichert 285 Zeichen

Warum frage ich das?

Ich arbeite an einem Projekt, während ich wiederkehrende Metafelder in einem Beitrag speichern werde. Woher:

  • Die Daten sind im Grunde genommen in Englisch, können aber manchmal auch in Bengali vorliegen
  • Die Daten wären assoziative Arrays mit einer Tiefe von 3 Ebenen (ich hoffe, ich habe Ebenen richtig verstanden):
array(
    1 => array(
        'key'=>'value',
        'key2'=>'value'
    ),
    2 => array(
        'key'=>'value',
        'key2'=>'value'
    )
)

Ich habe das Feld postmeta der Tabelle meta_value überprüft, es ist eine longtext, das heißt eine Länge von 4.294.967.295 Zeichen (4 GB).

Also brauche ich eine robuste Lösung für die Aufbewahrung.

13
Mayeenul Islam

Ich denke, nicht 100% sicher, dass dies der wahre Grund war, warum die WP Entwickler diesen Ansatz gewählt haben, aber der gesunde Menschenverstand sagt mir, dass Serialize die Variablentypen beibehält und eine integrierte Mini-Fehlererkennung hat und nur json speichert Zeichenfolgenwerte { key : value }. Wenn Sie also zu PHP zurückkehren, müssen Sie das Format erraten oder einen Parser dafür erstellen. Dies zwingt Sie dazu, auf zwei verschiedene Arten mit Ihren Daten umzugehen: Vorherige, Speichern der Daten als json und nach dem Dekodieren des json wird es als ein völlig anderes Objekt zurückgegeben.

Dies ist der Hauptgrund, warum der Größenunterschied PHP nicht nur ein Array speichert. Es speichert, wie viele Elemente im Array waren, als es serialisiert wurde, ihre Typen und ihre Werte.

Sie speichern nicht nur Schlüsselwertpaare in der Datenbank, sondern möglicherweise auch ein Objekt mit verschiedenen Variablentypen.

13
Ramy Deeb

Die JSON-Codierung wurde in PHP 5.2 eingeführt, WordPress ist viel älter und wurde für PHP 4 geboren (und entwickelt).

Die Serialisierung von Daten ist in WordPress allgegenwärtig. Ein Übergang von der PHP-Serialisierung zur JSON-Codierung würde ein großes Problem mit der Abwärtskompatibilität bedeuten, und wenn ich WordPress ein wenig kenne, wird dies niemals passieren.

Wenn Sie jedoch der Meinung sind, dass die JSON-Codierung für Sie besser ist als die PHP -Serialisierung, verwenden Sie sie einfach.

Wenn Sie eine Zeichenfolge (das ist die JSON-codierte Version Ihrer Daten) zum Posten von Metafunktionen übergeben, wird WordPress diese nicht berühren, Sie müssen jedoch beim Abrufen daran denken, die Daten mit JSON zu decodieren.

Wenn die Größe des DB-Speichers für Sie sehr wichtig ist, ist es wahrscheinlich die zusätzliche Arbeit wert, ansonsten lassen Sie WordPress einfach das verwenden, was es verwendet, und kümmern sich nicht darum.

Vielleicht können Sie auswerten, ob es sich um benutzerdefinierte Tabellen handelt, um Ihre Daten zu speichern.

6
gmazzap

Ich bin versucht, dies als "vorbehaltlich der Meinung" zu schließen, aber ich denke, es gibt ein paar gute Antworten auf die Frage. Ich werde mit "Geschichte" gehen.

1) json_encode ist in PHP core relativ neu.

json_encode

(PHP 5> = 5.2.0, PECL json> = 1.2.0) json_encode - Gibt die JSON-Darstellung eines Werts zurück

http://php.net/manual/en/function.json-encode.php

json_encode wäre in den Anfängen von WordPress nicht zuverlässig gewesen. Es wurde nur in "core" PHP in 5.2 gerollt, obwohl es lange zuvor als PECL-Erweiterung verfügbar war.

Zweitens, wenn Sie ein Objekt wie ein WP_Query-Objekt in json_encode einfügen, erhalten Sie ein stdClass-Objekt in json_decode. serialize/unserialize behält das Objekt bei.

3
s_ha_dum