Serialization 如何在关系数据库中存储值对象？

我正在处理一个大型项目，该项目有许多表示简单（不相关）值的对象。有时这些值是单个字符串，有时是两个字符串，有时是一个字符串和一个整数

目前，我们的关系数据库中有一个“值”表，其中包含以下列：

Id

，

Category

，

String1

，

String2

，

Int1

，

Int2

，

Double1

等等。这很方便，但很混乱

这些值都具有以下属性：

• 具有相同

  类别的每个对象都具有相同的属性（即已键入）

• 没有相关对象（唯一的键是

  Id

  主键）

我们如何走出这片混乱？在我看来，我们的选择如下：

只需根据需要不断添加列，忘记表和对象之间的语义映射。把它堆起来

为每个值对象创建一个新表。这将向数据库中添加大量表，其中大多数表的行数将少于6行。我担心所有这些额外的表都会添加到数据库中

仅为这些对象部署一个无模式的数据库（在我们的部署场景中不太可能）

创建一个包含

Id

、

Category

列和BLOB

Value

列的表，并将值对象序列化到Value列中。这是否可行

---

重申我们的选择。使用序列化是否存在任何警告或陷阱？有没有我不知道的选择？非常欢迎您的建议。

我是从中导航时偶然发现这一点的。虽然它已经很老了，但我很想回答这个问题，因为它不仅提出了一个非常明确的问题，而且还允许人们从整体上讨论数据库的非规范化

数据库非规范化有很多原因，甚至更多的借口。性能可能是最重要的，但数据分类困难（如手头的问题）肯定是最常见的。此外，有很多方法可以对数据库进行非规范化，其中很多都是由OP解决的

然而，事实是，在其他一切都失败之后，数据库应该作为最后手段进行非规范化。原因包括：

• 数据对人类和RDBMS来说都变得毫无意义。有些人很难理解甚至记住名为

  Integer1

  的字段或可能包含任何内容的序列化值的用途。RDBMS无法从序列化实体中提取值以对结果进行排序或应用聚合

• 维护易失性架构很难。数据库模式应该是常量是有原因的。另一方面，更高的层次取决于它。如果模式一夜之间改变，应用程序也应该改变，以反映新的状态。更糟糕的是，视图、存储过程和其他依赖的数据库组件也变得同样难以维护

• 无法强制执行约束，无法创建索引。没有必要将序列化字段定义为外键，也没有必要将其限制为一组特定的值。这取消了大量数据库的自我保护机制。更少的数据完整性意味着更多的管理成本。此外，索引在这里也同样没用，这会降低表的优化开放性

• 元数据最终必须存储为数据。想象一个多语言CMS，其中有一个主

  文章
  表来存放文章。现在，对于支持的每种语言，都有一个相应的
  article{lang}
  表来保存翻译（即
  article\u en
  ，
  article\u fr
  ，
  article\u es
  等）。为了记录文章的现有翻译，应创建一个“关系”表，其中包含
  文章
  表的外键、语言id、翻译表的表名以及翻译表的FK字段，但不能定义为FK字段。然后，尝试编写一个查询，统计每篇文章的可用翻译
  

所以尽量避免非规范化。如果实体可以在一定程度上进行分类，那么答案可能就是这样。为了支持任意属性，或者在分类不值得的情况下，使用保存规范化数据的表外键，这就足够了