Database 同事认为，在数据库中存储序列化的数据字符串并不违反1NF

1NF要求字段是原子的；也就是说，它应该只表示一个值

他说，因为他不希望数据是可搜索的或可读的，所以它不违反正常形式，并且该值表示单个对象

他说得对吗？

问题在于，单个值通常可以根据上下文分解为单独的值，例如，varchar可以是多个char值，浮点数可以是两个单独的数字。如果序列化数据与表所表示的关系不相关，则可以将其视为1NF

地址字段可以包含通用ContactInfo表中的街道名称和城市，但在地址表中，该字段不会被视为原子字段，因为地址表具有街道名称、城市、邮政编码等单独的属性。

定义原子字段

最近理论上的最新进展表明，通常理解的1NF的定义所依赖的原子性概念是模糊的，可能完全无法定义

例如，地图上的坐标，是原子值吗？通常，这样的值具有清晰可见的“X”和“Y”分量，这些分量的值可以从原子值中提取出来。如果某个东西可以从其他东西中提取出来，那么就有人怀疑其他东西在这个词的通常意义上是原子的，也就是说，不可进一步分解

正是出于这个原因，在地图上使用坐标类型的值是否违反了1NF？这一立场很难维持

---

由于这些原因，包含CSV列表的单个字符串不会正式违反1NF。这并不是说在此基础上设计数据库是一个非常好的主意。大多数时候，情况不会如此。但从形式上讲，它并不违反1NF或其剩余的任何内容。

字符串是单个值。它可以拆分成更小的字符串，这并不意味着您违反了1NF。如果您将大量信息编码为字符串，那么您可能没有充分利用DBMS的功能，即查询数据并对其实施约束的能力，但这是另一个问题。

是的，您的同事是对的

当前的智慧是，单个值可以任意复杂。它甚至可以是一张桌子。在Chris Date的书中，查找关系值属性。日期和时间戳是单个值，但它们都有内部结构

但如果某个类型确实具有内部结构，则dbms要么像选择当前\u时间戳时SQL那样忽略该内部结构，要么像从当前\u时间戳中选择EXTRACTYEAR时SQL那样提供在该内部结构上操作的函数

---

关键是用户不必编写任何过程代码来操作内部结构的内容。dbms提供这些功能，或者创建新类型的数据库设计器提供这些功能。

如果您不想搜索此数据，甚至不想引用外键，为了避免冗余，我将给同事+1。我可能必须同意同事的意见。想象一个BLOB或CLOB列。这些数据也可以包含大量非原子数据，但建模仍然是合理的。