PHP：序列化对象并将其保存在数据库中供以后使用是不是不好的设计？
我现在正在计划和研究从 MySQL 到 MongoDB 的切换，我有一个有趣的想法......我有一堆分层对象需要存储在数据库中。我当前的方法是在集合中包含一堆嵌入文档。他们永远不需要被寻找。仅序列化 PHP 对象，将它们粘贴到数据库中，然后在我想要使用它们时将它们反序列化回 PHP 对象是否有意义？另一种方法是使用 Doctrine 作为我的 ORM。
我的编程直觉告诉我，这是一个糟糕的设计并且有限制，但我觉得序列化和反序列化会非常快，并且消除了对 ORM 的需要。
你有什么意见？好的设计还是坏的设计？
I am planning and researching my switch from MySQL to MongoDB right now and I just had an interesting thought... I have a bunch of hierarchical objects that I need to store in the database. My current method is to have a bunch of embedded documents in a collection. They will never need to be searched for. Would it possibly make sense just to serialize the PHP objects, stick them in the DB, and then unserialize them back into PHP objects when I want to use them? The alternative is using Doctrine as my ORM.
My programming intuition tells me that this is bad design and is limiting, but I feel like serializing and unserializing would be very fast and eliminate the need for an ORM.
What's your opinion? Good design or bad design?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在许多情况下，这会被认为是糟糕的设计，但如果满足以下所有条件，它可能会起作用：
SELECT +deserialize()会比SELECT慢）In many cases this would be considered bad design, but it could work if all of the following apply:
SELECT+deserialize()will be slower than justSELECT)如果无法查询，为什么还要使用数据库？
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:
当您必须缓存某些内容（例如 RSS 提要）时，序列化对象非常有用。
我发现序列化它很有用，但我也会确保在不先反序列化它的情况下永远不能将其作为字符串进行编辑！
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!