web-dev-qa-db-fra.com

Pourquoi WordPress choisit-il la sérialisation des données sur json_encode?

Dans mon petit âge avec WordPress, j'ai vu WordPress lui-même et ses plugins amicaux utilisent PHP serialize() pour stocker des données dans la base de données dans de nombreux cas. Mais dans une recherche récente, j'ai trouvé un soutien sérieux de la communauté pour la json_encode() par rapport à la serialize().

Et j'ai personnellement testé un tableau associatif avec eux, ce qui montre:

  • serialize() enregistre 342 caractères
  • json_encode() enregistre 285 caractères

Pourquoi je demande ça?

Je suis sur un projet alors que je vais stocker des méta-champs répétés dans un post. Où:

  • Les données seraient essentiellement en anglais, mais peuvent parfois être en bengali
  • Les données seraient un tableau associatif, 3 niveaux de profondeur (j'espère avoir compris niveaux correctement):
array(
    1 => array(
        'key'=>'value',
        'key2'=>'value'
    ),
    2 => array(
        'key'=>'value',
        'key2'=>'value'
    )
)

J'ai vérifié le champ meta_value de la table postmeta, il s'agit d'une longtext, cela signifie une longueur de 4 294 967 295 caractères (4 Go).

J'ai donc besoin d'une solution robuste pour stocker les choses.

databasepost-meta
13
Mayeenul Islam

Je pense que ce n’est pas à 100% sûr que c’est la véritable raison pour laquelle les développeurs WP ont adopté cette approche, mais le bon sens me dit que la sérialisation préserve les types de variable et possède une mini-détection d’erreurs intégrée, et json stocke uniquement Les valeurs de chaîne { key : value }, de sorte que lorsque vous revenez à PHP, vous devrez deviner le format ou en créer un analyseur. Cela vous obligera à utiliser deux méthodes différentes pour gérer vos données: précédente, pour stocker les données sous forme de fichier json et après le décodage du fichier json, il reviendra sous la forme d'un objet totalement différent.

C’est la principale raison pour laquelle la différence de taille, PHP ne stocke pas seulement un tableau; il stocke combien d'éléments étaient dans le tableau quand il a été sérialisé, leurs types et leurs valeurs.

Vous ne stockez pas uniquement des paires clé-valeur dans la base de données, mais vous pouvez également stocker un objet avec différents types de variables.

13
Ramy Deeb

Le codage JSON a été introduit dans PHP 5.2, WordPress est bien plus ancien et il est né (et conçu pour) PHP 4.

La sérialisation des données est une chose omniprésente dans WordPress. Par conséquent, passer de PHP à l'encodage JSON constituerait un énorme problème de compatibilité, et si je connais un peu WordPress, cela n'arrivera jamais.

Cela dit, si vous pensez que l'encodage JSON est meilleur pour vous que la sérialisation PHP, utilisez-le.

Si vous transmettez une chaîne (c'est-à-dire la version codée JSON de vos données) pour publier des méta-fonctions, WordPress ne la touchera pas, mais vous devrez alors vous rappeler de décoder les données JSON lors de l'extraction.

Si la taille de stockage de la base de données est très importante pour vous, cela vaut probablement la peine de travailler davantage, sinon laissez simplement WordPress utiliser ce qu'il utilise sans vous en soucier.

Peut-être que vous pouvez évaluer s'il s'agit de tables personnalisées pour enregistrer vos données.

6
gmazzap

Je suis tenté de clore ceci en tant que "sujet à opinion" mais je pense qu'il y a quelques bonnes réponses à cette question. Je vais aller avec "l'histoire".

1) json_encode est relativement nouveau dans PHP core.

json_encode

(PHP 5> = 5.2.0, PECL json> = 1.2.0) json_encode - Retourne la représentation JSON d'une valeur

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

json_encode n'aurait pas été fiable dans les premiers jours de WordPress. Il a seulement été intégré à "core" PHP en 5.2, bien qu'il soit disponible en tant qu'extension PECL bien avant cela.

Deuxièmement, si vous alimentez un objet tel qu'un objet WP_Query dans json_encode, vous obtenez un objet stdClass sur json_decode. serialize/unserialize préservera l'objet.

3
s_ha_dum