Хорошо ли использовать сериализацию в PHP для хранения данных в БД?

Я нашел интересный комментарий в php.net о сериализации данных, чтобы сохранить его в БД.

В нем говорится следующее:

Пожалуйста! пожалуйста! пожалуйста! НЕ сериализуйте данные и поместите их в свой база данных. Сериализованный метод может использоваться таким образом, но при этом отсутствует точка реляционной базы данных и типов данных, присущих вашей базе данных двигатель. Это делает данные в вашей базе данных не переносимыми, сложными читать и может усложнять запросы. Если вы хотите, чтобы ваше приложение быть переносимым на другие языки, например, скажем, вы обнаружите, что хотите использовать Java для некоторой части вашего приложения, что имеет смысл использовать Java in, сериализация станет болью в ягодицах. Вам следует всегда иметь возможность запрашивать и изменять данные в базе данных без использования сторонний посреднический инструмент для манипулирования данными, которые необходимо вставить.

Я сталкивался с этим слишком много раз в своей карьере, это делает сложно поддерживать код, код с проблемами переносимости и данные это сложнее перейти на другие системы RDMS, новые схема и т.д. Это также имеет дополнительный недостаток, заключающийся в том, что он найдите свою базу данных на основе одного из полей, которые у вас есть. сериализованная.

Это не значит, что serialize() бесполезно. Это не... Хорошее место для это может быть файл кеша, который содержит результат данных например, интенсивная работа. Есть много других... Просто не злоупотребляйте сериализацией, потому что следующий парень, который приходит, будет иметь кошмара для поддержания или миграции.

Я хотел бы знать, является ли это стандартным представлением об использовании сериализации данных для целей БД. Значение, если это хорошая практика, использовать его иногда, или если его следует избегать.

Например, мне было предложено использовать сериализацию в последнее время.

В этом случае данные, которые мы должны были сохранить в таблице MySQL, были следующими:

  • Автомобильная марка.
  • Модель автомобиля.
  • Автомобильная версия.
  • Информация о машине.

Информация о машине была массивом, представляющим все свойства версии, поэтому это было большое переменное количество свойств (менее 100 свойств). Этот массив был сериализован.

Основная причина, по которой мне была предоставлена ​​возможность использования сериализации, была следующая:

Являясь большим количеством полей, лучше сериализовать данные в чтобы улучшить производительность вместо создания поля для каждого свойства или несколько таблиц.

Лично я больше согласен с комментарием на php.net, чем с этим последним asseveration, но я хотел бы получить здесь более квалифицированные мнения, чем мои.

Ответ 1

Являясь большим количеством полей, лучше сериализовать данные в чтобы улучшить производительность вместо создания поля для каждого свойство или несколько таблиц.

Я считаю, что это сильно зависит от варианта использования. Что делать, если есть класс Customer, который хочет иметь информацию обо всех автомобилях с дизельным двигателем или любых других конкретных данных для автомобиля (использование топлива кажется самым простым). Вам нужно будет достать все автомобили из базы данных, неэтериализировать их, проверить на свой счет и сохранить список со всеми автомобилями, релевантными для клиента.

Пример. Нам пришлось перенести некоторые личные данные из старой клиентской CMS на новую. Вместо того, чтобы каждый атрибут был хорошо сопоставлен в базе данных, вся информация была одной строкой в ​​старой базе данных. Поэтому вместо использования правильной структуры базы данных нам пришлось сделать много regex-foo, чтобы снова включить данные в правильную структуру. Конечно, это была дорогая (как денежная, так и рабочая) задача. В этом случае проблема не была такой огромной, поскольку объем данных был управляемым. Но представьте себе тот же сценарий с миллионами строк и больше, чем просто одну строку....

Прокомментированный вами комментарий относится только к структурам данных IMO. И я согласен, что хранить их не очень хорошо и эффективно. Намного проще иметь опечатку где-нибудь или добавить новое свойство, о котором не знают другие части языка. Это рано или поздно будет связано с проблемами.

С другой стороны, сохранение некоторых конфигураций, которые легче переносить, может быть случайным для сериализации данных. Вы можете утверждать, что внешние файлы настроек более подходят для такого случая, но это будет сильно зависеть от случая/философии/клиента/...

TL; DR В большинстве случаев использование правильной схемы рано или поздно принесет пользу всей разработке, скорости и мудрым способностям (поскольку я предпочитаю читать множество описаний таблиц, а не огромную, загадочную строку). Могут быть некоторые прецеденты, когда сериализация данных приемлема, поэтому давая конечный ответ, если это хорошо или плохо, практика не так проста и сильно зависит.