PHP: Is it bad design to serialize objects and stick them in the database for later?

本小妞迷上赌 提交于 2019-12-04 09:53:30

In many cases this would be considered bad design, but it could work if all of the following apply:

  1. You don't need to search on them
  2. You can accept (potentially) limited ability to query on them
  3. You don't need relational integrity or other constraints enforced by the RDBMS
  4. You know you'll never need to read them in a different language
  5. You're confident that you'll know how to deserialize, version, and migrate them properly when you update your class definition
  6. You're confident that the PHP serialization format will be stable across releases (or you are willing to write migration code, or it's a short-term project and you don't care)
  7. You're willing to accept a minor performance penalty (SELECT + deserialize() will be slower than just SELECT)

Why use a database if you can't query it ?

It kind of depends entirely on what you intend to do.

If it's always the same object each request deals with or there are no relationships between each request, it might be ok.

But to me there are a lot of downsides:

  • You might want to do something more advanced to the objects later
  • Serialized objects are kind of unreliable (not exactly ACID compliant)
  • There's nothing else that can read a serialized php object, you might want to use something else instead.

Serializing objects is VERY useful when you have to cache things, such as RSS feeds.

I find it good use to serialize it, but I would also make sure that that can never be editing as a string without unserializing it first!

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!