Чому WordPress вибирає серіалізацію даних через json_encode?

У своєму маленькому віці з WordPress я бачив сам WordPress і його дружні плагіни використовують PHP serialize()для зберігання даних у db у багатьох випадках. Але в нещодавньому пошуку я знайшов серйозну підтримку громади для тих, хто json_encode()переживає serialize().

• Тест, який виявився json_encode()кращим, ніж serialize()- StackOverflow
• Причини, чому json_encode()можна використовувати, а чому ні, - StackOverflow

І я особисто тестував асоціативний масив з обома з них, що показує:

• serialize() магазинів 342 символів
• json_encode() магазинів 285 символів

Чому я це прошу?

Я працюю над проектом, поки збираюся зберігати повторювані метаполя до публікації. Де:

• Дані, в основному, англійською мовою, але іноді можуть бути бенгальською
• Дані будуть асоціативним масивом, глибиною 3 рівня (сподіваюся, що я зрозумів рівні правильно):

array(
    1 => array(
        'key'=>'value',
        'key2'=>'value'
    ),
    2 => array(
        'key'=>'value',
        'key2'=>'value'
    )
)

Я перевірив поле postmetaтаблиці " meta_valueце" longtext, це означає довжину 4 294 967 295 символів (4 ГБ).

Тому мені потрібно надійне рішення для зберігання речей.

Я думаю, не на 100% впевнений, що це була справжня причина, що розробники WP застосували такий підхід, але здоровий глузд говорить мені, що серіалізація зберігає типи змінних і має міні-вбудований спосіб виявлення помилок, а json зберігає лише рядкові значення { key : value }, тому коли ви поверніться до PHP, вам доведеться відгадати формат або зробити для нього аналізатор. Це змусить вас мати два різних способи обробки даних: попередній, зберігання даних як json, а після декодування json повернеться як абсолютно інший об'єкт.

Це основна причина різниці в розмірах, PHP зберігає не тільки масив; він зберігає, скільки елементів було в масиві, коли він був серіалізований, їх типи та їх значення.

Ви не зберігаєте в базі даних лише пари ключових значень, але ви також можете зберігати об'єкт з різними типами змінних.

Кодування JSON було введено в PHP 5.2, WordPress значно старший, і він народився (і призначений для) PHP 4.

Серіалізація даних - це поширена річ у WordPress, тому перехід від серіалізації PHP до кодування JSON означав би величезну проблему сумісності із зворотним процесом, і якщо я трохи знаю WordPress, цього ніколи не станеться.

Це означає, що якщо ви думаєте, що кодування JSON для вас краще, ніж серіалізація PHP, просто використовуйте його.

Якщо ви передаєте рядок (тобто кодовану JSON версію своїх даних) для розміщення мета-функцій, WordPress не торкнеться її, але тоді вам потрібно запам'ятати дані JSON-декодування при пошуку.

Якщо розмір пам’яті БД для вас дуже важливий, він, ймовірно, вартий додаткової роботи, інакше просто дозвольте WordPress використовувати те, що він використовує, і не дбає про це.

Можливо, ви можете оцінити, чи це стосується спеціальних таблиць для збереження даних.

Мені спокушається закрити це як "предмет на думку", але я думаю, що є кілька хороших відповідей на питання. Я збираюся піти з "історією".

1) json_encodeвідносно новий в ядрі PHP.

json_encode

(PHP 5> = 5.2.0, PECL json> = 1.2.0) json_encode - Повертає представлення значення JSON

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

json_encodeне був би надійним у перші дні WordPress. Він був згорнутий лише в "основний" PHP в 5.2, хоча він був доступний як розширення PECL задовго до цього.

По-друге, якщо ви подаєте такий об'єкт, як WP_Queryоб'єкт, json_encodeви отримуєте stdClassоб'єкт json_decode. serialize/ unserializeзбереже об’єкт.