Por que o WordPress escolheu serialização de dados em json_encode?

12

Na minha pequena idade com o WordPress, eu vi o próprio WordPress e seus plugins amigáveis estão usando PHP serialize() no armazenamento de dados em db em muitos casos. Mas em uma pesquisa recente, encontrei um suporte sério da comunidade para o json_encode() sobre o serialize() .

E eu pessoalmente testei um array associativo com ambos, que mostra:

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

Por que estou perguntando isso?

Estou em um projeto enquanto vou armazenar metadados repetidos em um post. Onde:

  • Os dados seriam basicamente em inglês, mas às vezes podem ser bengali
  • Os dados seriam um array associativo, com 3 níveis de profundidade (espero ter entendido níveis corretamente):
array(
    1 => array(
        'key'=>'value',
        'key2'=>'value'
    ),
    2 => array(
        'key'=>'value',
        'key2'=>'value'
    )
)

Eu verifiquei o campo postmeta da tabela meta_value , é longtext , isso significa um tamanho de 4.294.967.295 caracteres (4 GB).

Então eu preciso de uma solução robusta para armazenar coisas.

    
por Mayeenul Islam 07.04.2015 / 17:33

3 respostas

13

Eu acho que não tenho 100% de certeza que essa foi a verdadeira razão pela qual os desenvolvedores do WP tomaram essa abordagem, mas o senso comum me diz que serializar preserva os tipos de variáveis e possui um mini construído na detecção de erros, e json armazena apenas valores de string { key : value } , então quando você voltar ao PHP, você terá que adivinhar o formato ou fazer um analisador para ele. Isto irá forçá-lo a ter duas maneiras diferentes para lidar com seus dados: anterior, para armazenar os dados como json e depois de decodificar o json, ele retornará como um objeto totalmente diferente.

Este é o principal motivo da diferença de tamanho, o PHP está armazenando não apenas uma matriz; está armazenando quantos elementos estavam na matriz quando ela foi serializada, seus tipos e seus valores.

Você não está armazenando apenas pares de valores de chave no banco de dados, mas também pode estar armazenando um objeto com diferentes tipos de variáveis.

    
por Ramy Deeb 07.04.2015 / 17:57
6

A codificação JSON foi introduzida no PHP 5.2, o WordPress é muito mais antigo e nasceu (e foi projetado para) o PHP 4.

A serialização de dados é uma coisa difundida no WordPress, então mudar da serialização do PHP para a codificação JSON significaria um enorme problema de compatibilidade com versões anteriores, e se eu conheço o WordPress um pouco, isso nunca acontecerá.

Dito isso, se você acha que a codificação JSON é melhor para você do que a serialização do PHP, use-a.

Se você passar uma string (que é a versão codificada em JSON dos seus dados) para postar funções meta, o WordPress não irá tocá-la, mas você precisa se lembrar dos dados de decodificação JSON na recuperação.

Se o tamanho do armazenamento do banco de dados for muito importante para você, provavelmente valerá o trabalho adicional; caso contrário, deixe o WordPress usar o que ele usa e não se importe com isso.

Talvez você possa avaliar se é o caso de tabelas personalizadas para salvar seus dados.

    
por gmazzap 07.04.2015 / 18:04
3
Estou tentado a fechar isso como "sujeito à opinião", mas acho que há algumas boas respostas para a pergunta. Eu vou com "história".

1) json_encode é relativamente novo no núcleo do PHP.

  

json_encode

     

(PHP 5 > = 5.2.0, PECL json > = 1.2.0) json_encode - Retorna o JSON   representação de um valor

     

enlace

json_encode não seria confiável nos primeiros dias do WordPress. Ele foi lançado apenas no PHP "core" em 5.2, embora estivesse disponível como uma extensão PECL muito antes disso.

Em segundo lugar, se você alimentar um objeto, como WP_Query , em json_encode , receberá um objeto stdClass em json_decode . serialize / unserialize preservará o objeto.

    
por s_ha_dum 07.04.2015 / 18:00