¿Por qué WordPress elige la serialización de datos sobre json_encode?

12

En mi pequeña edad con WordPress, he visto WordPress y sus complementos amigables están usando PHP serialize() en el almacenamiento de datos en db en muchos casos. Pero en una búsqueda reciente encontré un serio apoyo comunitario para el json_encode() sobre el serialize() .

Y personalmente probé una matriz asociativa con ambos, que muestra:

  • serialize() almacena 342 caracteres
  • json_encode() almacena 285 caracteres

¿Por qué estoy preguntando esto?

Estoy en un proyecto mientras voy a almacenar metacampos repetidos en una publicación. Donde:

  • Los datos estarían básicamente en inglés, pero a veces pueden ser bengalíes
  • Los datos serían una matriz asociativa, 3 niveles de profundidad (espero que haya entendido niveles correctamente):
array(
    1 => array(
        'key'=>'value',
        'key2'=>'value'
    ),
    2 => array(
        'key'=>'value',
        'key2'=>'value'
    )
)

He comprobado que el campo postmeta de la tabla meta_value es un longtext , que significa una longitud de 4,294,967,295 caracteres (4GB).

Necesito una solución robusta para almacenar cosas.

    
pregunta Mayeenul Islam 07.04.2015 - 17:33

3 respuestas

13

Creo que no estoy 100% seguro de que esta sea la verdadera razón por la que los desarrolladores de WP adoptaron este enfoque, pero el sentido común me dice que la serialización conserva los tipos de variables y tiene una mini detección de errores integrada, y json almacena solo valores de cadena { key : value } , así que cuando vuelva a PHP tendrá que adivinar el formato o hacer un analizador para ello. Esto te obligará a tener dos formas diferentes de manejar tus datos: anterior, almacenar los datos como json y después de descodificar el json volverá como un objeto totalmente diferente.

Esta es la razón principal por la diferencia de tamaño, PHP está almacenando no solo una matriz; almacena cuántos elementos había en la matriz cuando se serializó, sus tipos y sus valores.

No está almacenando solo pares de valores clave en la base de datos, pero también puede estar almacenando un objeto con diferentes tipos de variables.

    
respondido por el Ramy Deeb 07.04.2015 - 17:57
6

La codificación JSON se introdujo en PHP 5.2, WordPress es mucho más antiguo y nació (y fue diseñado para) PHP 4.

La serialización de datos es algo generalizado en WordPress, por lo que pasar de la serialización de PHP a la codificación JSON significaría un gran problema de compatibilidad con versiones anteriores, y si conozco un poco WordPress, eso nunca sucederá.

Dicho esto, si crees que la codificación JSON es mejor para ti que la serialización de PHP, solo úsala.

Si pasa una cadena (que es la versión codificada en JSON de sus datos) para publicar funciones meta, WordPress no la tocará, pero luego debe recordar los datos de la descodificación JSON en la recuperación.

Si el tamaño de almacenamiento de la base de datos es muy importante para usted, es probable que valga la pena el trabajo adicional, de lo contrario, deje que WordPress use lo que usa y no le importe.

Tal vez, puede evaluar si es el caso de tablas personalizadas para guardar sus datos.

    
respondido por el gmazzap 07.04.2015 - 18:04
3

Estoy tentado de cerrar esto como "sujeto a opinión" pero creo que hay un par de buenas respuestas a la pregunta. Voy a ir con "historia".

1) json_encode es relativamente nuevo en el núcleo de PHP.

  

json_encode

     

(PHP 5 > = 5.2.0, PECL json > = 1.2.0) json_encode - Devuelve el JSON   representación de un valor

     

enlace

json_encode no hubiera sido confiable en los primeros días de WordPress. Solo se incorporó a PHP "central" en 5.2, aunque estaba disponible como una extensión PECL mucho antes.

Segundo, si alimenta un objeto como un objeto WP_Query en json_encode , obtiene un objeto stdClass en json_decode . serialize / unserialize mantendrá el objeto.

    
respondido por el s_ha_dum 07.04.2015 - 18:00

Lea otras preguntas en las etiquetas