Я наткнулся на интересный комментарий в php.net о сериализации данных для сохранения это в БД.

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

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

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

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

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

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

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

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

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

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

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

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

13
rfc1484 26 Сен 2012 в 15:42
2
Мое мнение (и, следовательно, не ответ) заключается в том, что если вам нужно сериализовать, ваша схема БД, вероятно, может использовать некоторую работу (возможно, даже вы не используете правильный инструмент для работы - возможно, решение NoSQL будет лучше, чем СУБД).
 – 
Leigh
26 Сен 2012 в 16:22

1 ответ

Лучший ответ

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

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

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

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

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

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

11
DrColossos 26 Сен 2012 в 16:30
Я пытался сформулировать ответ в этом духе, но вы справились гораздо лучше. +1
 – 
vascowhite
26 Сен 2012 в 18:04