它说如下：
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.
我想知道这是否是关于将数据序列化用于数据库目的的标准视图.这意味着有时使用它是否是一种好习惯,或者应该避免使用它.
例如,我被指示最近使用序列化.
在这种情况下,我们必须保存到MysqL表中的数据如下：
>汽车品牌.
>汽车模型.
>汽车版.
>汽车信息
Car info是一个表示版本所有属性的数组,因此它是一个大量可变的属性(在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.
解决方法
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.
我认为这高度依赖于用例.如果有一类客户希望拥有关于所有运行柴油的汽车或汽车的任何其他特定数据的信息(使用燃料似乎最简单).您需要从数据库中获取所有汽车,对其进行反序列化,检查属性并保留列表中包含与客户相关的所有汽车.
示例：我们必须将一些与人员相关的数据从旧客户CMS移动到新客户CMS.而不是将每个属性很好地映射到数据库上,整个信息是旧数据库中的单个字符串.因此,我们不必使用适当的数据库结构,而是需要使用大量的regex-foo来将数据再次转换为适当的结构.当然,这是一项昂贵的(包括货币和工作负载)任务.在这种情况下,问题并不是那么大,因为数据量是可管理的.但想象同样的情况有数百万行,而不仅仅是一个字符串….
您发布的评论仅涉及IMO的数据结构.我同意,存储这些并不是很好也不是很有效.在某处输入拼写错误或添加语言的其他部分不知道的新属性会容易得多.这迟早会引起问题.
另一方面,存储一些更容易移植的配置可能是序列化数据的好例子.您可以争辩说外部设置文件对于这种情况更为理想,但这将高度依赖于案例/哲学/客户/ ……
TL; DR在大多数情况下,使用适当的模式迟早会有利于整个开发,速度明智和复杂性(因为我更喜欢阅读许多表格描述而不是巨大的,神秘的字符串).可能存在一些用例,其中序列化数据是可接受的,因此如果这是好的或坏的做法给出有限的答案并不那么容易和高度依赖.
