php - 在 PHP 中使用序列化将数据存储到数据库中是一个好习惯吗？

Question

我在 php.net 中发现了一条有趣的评论关于序列化数据以将其保存到数据库中。

它的内容如下:

Please! please! please! DO NOT serialize data and place it into your database. Serialize can be used that way, but that's missing the point of a relational database and the datatypes inherent in your database engine. Doing this makes data in your database non-portable, difficult to read, and can complicate queries. If you want your application to be portable to other languages, like let's say you find that you want to use Java for some portion of your app that it makes sense to use Java in, serialization will become a pain in the buttocks. You should always be able to query and modify data in the database without using a third party intermediary tool to manipulate data to be inserted.

I've encountered this too many times in my career, it makes for difficult to maintain code, code with portability issues, and data that is it more difficult to migrate to other RDMS systems, new schema, etc. It also has the added disadvantage of making it messy to search your database based on one of the fields that you've serialized.

That's not to say serialize() is useless. It's not... A good place to use it may be a cache file that contains the result of a data intensive operation, for instance. There are tons of others... Just don't abuse serialize because the next guy who comes along will have a maintenance or migration nightmare.

我想知道这是否是关于将序列化数据用于数据库目的的标准 View 。意思是有时使用它是否是一个好的做法，或者是否应该避免。

例如，我最近被指示使用序列化自己。

在本例中，我们必须保存到 MySQL 表中的数据如下:

• 汽车品牌。
• 汽车型号。
• 汽车版。
• 汽车信息。

汽车信息是一个代表版本所有属性的数组，因此属性数量很大(少于 100 个属性)。该数组是要序列化的数组。

我使用序列化的主要原因如下:

Being a large number of fields, it is better to serialize the data in order to improve performance instead of creating a field for each property or multiple tables.

就我个人而言，我更同意 php.net 中的评论，而不是最后的断言，但我想在此提出比我更合格的意见。

Answer 1

Being a large number of fields, it is better to serialize the data in order to improve performance instead of creating a field for each property or multiple tables.

我认为这高度依赖于用例。如果有一个类 Customer 想要了解所有运行柴油的汽车的信息或该汽车的任何其他特定数据(使用燃料似乎最简单)，该怎么办？您需要从数据库中获取所有汽车，对其进行反序列化，检查其属性并保留与客户相关的所有汽车的列表。

示例:我们必须将一些与人员相关的数据从旧客户 CMS 移动到新客户 CMS。整个信息不是旧数据库中的单个字符串，而是将每个属性很好地映射到数据库上。因此，我们必须执行大量 regex-foo 来再次将数据转换为正确的结构，而不是使用正确的数据库结构。当然，这是一项昂贵的任务(无论是金钱还是工作量)。在这种情况下，问题并不是那么大，因为数据量是可以管理的。但想象一下同样的场景，有数百万行并且不仅仅是一个字符串......

您发布的评论仅讨论数据结构(IMO)。我同意，存储这些不是很好，效率也不是很高。在某个地方出现拼写错误或添加语言其他部分不知道的新属性会更容易。这迟早会导致问题。

另一方面，存储一些更容易移植的配置可能是序列化数据的好情况。您可能会说外部设置文件对于这种情况更理想，但这将高度依赖于案例/理念/客户/...

TL;博士 在大多数情况下，使用正确的模式迟早会对整个开发有利，无论是速度方面还是复杂性方面(因为我更喜欢阅读许多表描述而不是巨大的、神秘的字符串)。可能在某些用例中序列化数据是可以接受的，因此给出有限的答案(这是好还是坏的做法)并不那么容易且高度依赖。