数据库必须有主键吗？一场LinkedIn论战撕开了建模的哲学伤口

“实际观察到的数据，可能根本就没有关系模型所要求的自然键。数据域也不是能清晰定义的——我们甚至没法就‘什么是国家’达成一致，也不知道该怎么妥善跟踪人类语言，连编程语言的语义标准都锁不死。更头疼的是，立法常常禁止存储能唯一标识一个人的任何键。至于规范化，它根本就是高速分析的死对头——没有哪个分析型系统会用它。”

这段话不是数据库教科书的反面案例，而是真实流传在LinkedIn上的一句吐槽。它直指关系模型的两个根基：一切数据都必须有唯一标识（键），所有存储都应该消除冗余（规范化）。发帖人得出结论：理论很美，但现实里到处是例外。

很快，名叫Eduardo Bellani的架构师跳了出来。他没有纠结哪个数据库引擎跑得更快，而是把扳手伸向了更底层：你确定你说的“没有键”是真的没有，还是你没发现而已？

Bellani给出的定义简单到近乎哲学：关系模型中的键，就是那个能让一句断言在话语域中被唯一指认的部分。比如“Bob的薪水是100”，这句话里的“Bob”就是一种键：它划定了这句话说的是谁。只要你承认自己有办法存储Bob的薪水，你就已经承认有办法唯一指向Bob。所以，不是数据没有自然键，而是任何能被人存进系统的数据，都必定已经带着某种键——哪怕这个键只在应用程序的内存里存活了几微秒。

原始帖子里那条“找不到国家的主键”的抱怨，恰好撞上了同一个逻辑。国家作为一个概念确实边界模糊，但只要你试图在系统里写入一条与国家有关的记录——比如税率、首都、官方语言——你就在那一刻固定了这句断言指的是哪个实体。“国家”此时已经拥有了足以在对应话语域里被唯一识别的键。讨论现实世界的复杂性，不等于否定键的存在，只是承认发现键的代价很大。

顺着同样的拆解，Bellani把矛头转向了立法困局。如果法律禁止存储个人身份证号、手机号甚至姓名，是不是键就被法律杀死了？他的回答堪称锋利：立法改变的不是“有没有键”，而是整个谓词被迫改变。以前“用户X的年龄是Y”是一个可记录的谓词，现在法律强制你只能记录“某地区30岁以上用户数的总和”——谓词变了，键也随之改变，但“必须有键”的要求没有消失。限制存储内容，从来不会让关系模型破产，只是让开发者重新设计一句仍能承载唯一性的断言而已。

这三层回应，每一层都在重复同一个信号：键不是关系模型的紧箍咒，而是任何有意义的数据叙事的骨架。你没法表达一个想法而同时完全不指向它，也没法在系统里保存一句事实而不给它挂上一个能反复找回的把手。

最容易被误伤的受害者可能是“规范化”。原始帖子把分析系统绕着规范化走的现象解读为“规范化天生慢”。但规范化究竟在做什么？它只是要求一个经过编码的关系只对应一个逻辑谓词。换句话说，一张表只说一件事，不把顾客信息、订单金额和物流状态煮成一锅粥。这原则上和性能毫无必然联系。

那我们明明看到高度规范化的系统有时跑得气喘吁吁，又是怎么回事？答案在别处：是为了查询方便而刻意引入的冗余结构，是因为索引策略、存储引擎、计算资源分配没能跟上语义模型的简洁。规范化本身没有把数据打入慢速地狱，是人自己选择在规范化的纯净地基上叠加了一层又一层的性能折衷。原始帖子里那个“没有分析系统用规范化”的观察，充其量只说明了工程实现的现实，却证明不了规范化的设计原罪。

Bellani的最终一击，把话题从数据库拉进了本体论。键和规范化的必要性，并不是某个模型在40年前的心血来潮。它折射的是我们试图建模的那个世界本身的特性。你必须能唯一地指称事物，而为了做到这点，事物就必须拥有稳定、能相互区分的“本质”。

“什么是国家”很难定义，不代表国家的本质不存在，只代表我们发现本质的过程磕磕绊绊。这是认识论上的困难，而不是本体论上的缺失。同样，在系统里到底用UUID还是业务主键，到底拆成几张表，表面上是技术选型，底层却是一句追问：我们想要言说的那个世界，究竟由哪些不可再混淆的东西构成？

关系模型没有把人工秩序强加给无形式的数据，它只是把一切连贯话语都预先预设的一件事挑明了：世界是充满了具有本质的事物的。任何一个系统，只要它还想忠实地反映现实、真正帮人做事，就绕不开对这层本质的发现与尊重。那场LinkedIn上的争论，与其说是数据库原理的攻防，不如说是给所有工程师转播了一期哲学课：你每建一次表、每选一次主键，都在替你要解决的问题回答一个深不见底的问题——这个玩意到底是什么？