Я наткнулся на интересный комментарий в php.net о сериализации данных, чтобы сохранить его в БД.
В нем говорится следующее:
Пожалуйста! пожалуйста! пожалуйста! НЕ сериализуйте данные и поместите их в свою базу данных. Сериализация может использоваться таким образом, но в этом отсутствует точка реляционной базы данных и типы данных, присущие вашему движку базы данных. Это делает данные в вашей базе данных не переносимыми, трудночитаемыми и может усложнять запросы. Если вы хотите, чтобы ваше приложение было переносимым на другие языки, например, скажем, вы обнаружите, что хотите использовать Java для некоторой части вашего приложения, что имеет смысл использовать Java, сериализация станет болью в ягодицах. Вы всегда должны иметь возможность запрашивать и изменять данные в базе данных без использования стороннего посреднического инструмента для манипуляции данными, которые необходимо вставить.
Я сталкивался с этим слишком много раз в своей карьере, это затрудняет поддержание кода, кода с проблемами переносимости и данных, которые сложнее переносить на другие системы RDMS, новую схему и т. Д. Это также имеет дополнительный недостаток сделать его беспорядочным для поиска вашей базы данных на основе одного из полей, которые вы сериализовали.
- Методы сериализации cookie Javascript / PHP?
- Хранить массив в cookie
- Что может вызвать сбой в функции сериализации PHP?
- Что это за строка? Как я неэтериализую эту строку?
- Сериализованное отражение PHP
Это не значит, что serialize () бесполезен. Это не так … Хорошим местом для использования может быть файл кеша, который, например, содержит результат операции с интенсивным использованием данных. Есть много других … Просто не злоупотребляйте сериализацией, потому что следующий парень, который приходит, будет иметь кошмар для обслуживания или миграции.
Я хотел бы знать, является ли это стандартным представлением об использовании сериализации данных для целей БД. Значение, если это хорошая практика использовать его иногда, или если его следует избегать.
Например, мне было поручено использовать сериализацию в последнее время.
В этом случае данные, которые мы должны были сохранить в таблице MySQL, были следующими:
Информация о машине была массивом, представляющим все свойства версии, поэтому это было большое количество переменных свойств (менее 100 свойств). Этот массив был сериализован.
Основной причиной, по которой я получил сериализацию, было следующее:
Являясь большим количеством полей, лучше сериализовать данные для повышения производительности вместо создания поля для каждого свойства или нескольких таблиц.
Лично я больше согласен с комментарием на php.net, чем с этим последним asseveration, но я хотел бы получить здесь более квалифицированные мнения, чем мои.
Являясь большим количеством полей, лучше сериализовать данные для повышения производительности вместо создания поля для каждого свойства или нескольких таблиц.
Я считаю, что это сильно зависит от варианта использования. Что, если есть класс Customer который хочет иметь информацию обо всех автомобилях, на которых работает дизель, или каких-либо других конкретных данных для автомобиля (использование топлива кажется самым простым). Вам нужно будет получить все автомобили из базы данных, неэтериализировать их, проверить на свой счет и сохранить список со всеми автомобилями, релевантными для клиента.
Пример. Нам пришлось перенести некоторые личные данные из старой клиентской CMS на новую. Вместо того, чтобы каждый атрибут был хорошо сопоставлен в базе данных, вся информация была одной строкой в старой базе данных. Поэтому вместо использования правильной структуры базы данных нам пришлось сделать много regex-foo, чтобы снова включить данные в правильную структуру. Конечно, это была дорогая (как денежная, так и рабочая) задача. В этом случае проблема не была такой огромной, поскольку объем данных был управляемым. Но представьте себе тот же сценарий с миллионами строк и больше, чем только одна строка ….
В опубликованном вами комментарии речь идет только о структурах данных IMO. И я согласен, что хранить их не очень хорошо и эффективно. Намного проще иметь опечатку где-нибудь или добавить новое свойство, о котором не знают другие части языка. Это рано или поздно будет связано с проблемами.
С другой стороны, сохранение некоторых конфигураций, которые легче переносить, может быть примером OK для сериализации данных. Вы можете утверждать, что внешние файлы настроек более подходят для такого случая, но это будет сильно зависеть от случая / философии / клиента / …
TL; DR. В большинстве случаев использование правильной схемы рано или поздно принесет пользу всей разработке, скорости и мудрым способностям (поскольку я предпочитаю читать множество описаний таблиц, а не огромную загадочную строку). Могут быть некоторые варианты использования, когда сериализация данных приемлема, поэтому давая конечный ответ, если это хорошо или плохо, практика не так проста и сильно зависит.