Dlaczego WordPress wybiera serializację danych zamiast json_encode?

W moim młodym wieku z WordPress widziałem, że sam WordPress i jego przyjazne wtyczki używają PHP serialize()do przechowywania danych w db w wielu przypadkach. Ale podczas ostatnich poszukiwań znalazłem poważne wsparcie społeczności dla json_encode()ponad serialize().

• Sprawdzony test json_encode()jest lepszy niż serialize()- StackOverflow
• Powody, dla json_encode()których można użyć, a dlaczego nie - StackOverflow

Osobiście przetestowałem tablicę asocjacyjną z nimi obojga, która pokazuje:

• serialize() przechowuje 342 znaki
• json_encode() przechowuje 285 znaków

Dlaczego o to pytam?

Pracuję nad projektem, gdy zamierzam przechowywać powtarzające się pola meta w poście. Gdzie:

• Dane byłyby w zasadzie w języku angielskim, ale czasami mogą być bengalskie
• Dane byłyby tablicą asocjacyjną, głębokość 3 poziomów (mam nadzieję, że poprawnie zrozumiałem poziomy ):

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

Sprawdziłem pole postmetatabeli, meta_valueto jest longtext, co oznacza długość 4 294 967 295 znaków (4 GB).

Potrzebuję więc solidnego rozwiązania do przechowywania rzeczy.

Myślę, że nie jestem w 100% pewien, że to był prawdziwy powód, dla którego programiści WP przyjęli to podejście, ale zdrowy rozsądek mówi mi, że serializacja zachowuje typy zmiennych i ma wbudowane mini wykrywanie błędów, a json przechowuje tylko wartości ciągu { key : value }, więc kiedy wróć do PHP, musisz odgadnąć format lub utworzyć parser dla niego. Zmusi cię to do posiadania dwóch różnych sposobów postępowania z danymi: wcześniej, do przechowywania danych jako JSON, a po zdekodowaniu JSON powróci jako zupełnie inny obiekt.

Jest to główny powód różnicy wielkości, PHP przechowuje nie tylko tablicę; przechowuje, ile elementów było w tablicy, kiedy została serializowana, ich typy i ich wartości.

Nie przechowujesz tylko par klucz-wartość w bazie danych, ale możesz także przechowywać obiekt o różnych typach zmiennych.

Kodowanie JSON zostało wprowadzone w PHP 5.2, WordPress jest znacznie starszy i narodził się (i został zaprojektowany) dla PHP 4.

Serializacja danych jest wszechobecna w WordPress, więc przejście od serializacji PHP do kodowania JSON oznaczałoby ogromny problem z kompatybilnością wsteczną, a jeśli znam trochę WordPress, to nigdy się nie zdarzy.

To powiedziawszy, jeśli uważasz, że kodowanie JSON jest dla Ciebie lepsze niż serializacja PHP, po prostu użyj go.

Jeśli przekażesz ciąg znaków (czyli wersję danych zakodowaną w JSON), aby opublikować meta-funkcje, WordPress go nie dotknie, ale musisz pamiętać o dekodowaniu danych JSON podczas pobierania.

Jeśli rozmiar pamięci DB jest dla Ciebie bardzo ważny, to prawdopodobnie jest wart dodatkowej pracy, w przeciwnym razie po prostu pozwól WordPressowi wykorzystać to, czego używa, i nie przejmuj się nim.

Być może możesz ocenić, czy w przypadku niestandardowych tabel zapisujesz swoje dane.

Kusi mnie, by zamknąć to jako „zależne od opinii”, ale myślę, że istnieje kilka dobrych odpowiedzi na to pytanie. Idę z „historią”.

1) json_encodejest stosunkowo nowy w rdzeniu PHP.

json_encode

(PHP 5> = 5.2.0, PECL json> = 1.2.0) json_encode - Zwraca reprezentację JSON wartości

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

json_encodenie byłby wiarygodny we wczesnych dniach WordPress. Został zwinięty w „rdzeń” PHP w wersji 5.2, choć na długo był dostępny jako rozszerzenie PECL.

Po drugie, jeśli nakarmisz obiekt taki jak WP_Queryobiekt json_encode, otrzymasz stdClassobiekt json_decode. serialize/ unserializezachowa obiekt.