Сериализация объектов в PHP проблемах?

Question

Мне было интересно, есть ли какая-либо причина держаться подальше от сериализации объектов в PHP. Мой вариант использования для отложенной обработки. Пример: почтовая очередь, в которой почтовый объект сериализуется при получении запроса на отправку, сохраняется в БД и не сериализуется запланированным рабочим скриптом.

Альтернатива - хранить всю информацию, которая необходима объекту, в базе данных и строить объект в рабочем сценарии. Недостатком этого является то, что база данных будет привязана к структуре объекта, и я не хочу этого делать.

Answer 1

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

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

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

Answer 2

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