论键、本质与性能
摘要
一篇博客文章,为关系模型中键和规范化的必要性辩护,认为它们反映了关于现实进行连贯话语所需的本体论条件,反驳了关于定义键和域的实际困难之类的批评。
<p><a href="https://lobste.rs/s/kry4v6/on_keys_essences_performance">评论</a></p>
查看缓存全文
缓存时间: 2026/07/14 20:20
# 关于键、本质与性能
来源:https://ebellani.github.io/blog/2026/on-keys-essences-and-performance/
## 关于键、本质与性能
2026年7月14日
作者:Eduardo Bellani
LinkedIn上最近的一次讨论(https://www.linkedin.com/feed/update/urn:li:activity:7482151625499820033?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A7482151625499820033%2C7482168072209092608%29&replyUrn=urn%3Ali%3Acomment%3A%28activity%3A7482151625499820033%2C7482487327894765568%29&dashCommentUrn=urn%3Ali%3Afsd_comment%3A%287482168072209092608%2Curn%3Ali%3Aactivity%3A7482151625499820033%29&dashReplyUrn=urn%3Ali%3Afsd_comment%3A%287482487327894765568%2Curn%3Ali%3Aactivity%3A7482151625499820033%29)围绕“数据是什么以及如何存储”展开,这促使我写下这篇短文,因为我坚信所讨论的问题对于构建反映现实、进而帮助人们的系统至关重要。
以下是被引用作者的观点:
> 我的意思是,我们在现实世界中观察到的实际数据——可能并不具备模型所要求的自然键。数据域也无法清晰界定。我们甚至无法就“国家”的定义达成一致,也无法确定如何正确追踪人类语言,更无法锁定编程语言语义应如何运作的标准。而且,当法律通常禁止存储任何键时,我们又能用什么键来唯一标识一个人?规范化也是一种非常糟糕的数据组织方式,尤其当数据需要快速分析时(这也正是几乎没有任何分析系统采用规范化模型的原因)。
我将上述论点拆解为几个命题,并在下面逐一给出我的回应:
1. `现实观察到的数据可能不具备(关系模型所要求的)自然键`
我会将关系模型中的键定义为“所指示命题中能唯一指称给定论域内对象的那部分”。如果接受这一定义,那么被指示的事物怎么可能没有键呢?如果我们在指示某物,就需要以某种方式无歧义地指称它。任何处理数据的系统(无论是在应用层还是数据库管理系统层)都会这样做。
2. `数据域无法清晰界定`
这与上述问题相同,但发生在谓词层面而非命题层面。如果我们能够指称一个命题(例如“鲍勃的工资是100”),那么我们当然也能指称其谓词(“某人的工资是X”)。如果不能,我们就无法在任何给定的系统中处理它。
3. `法律禁止使用键`
那么这样的法律将迫使谓词发生改变(也许只能使用聚合数据?)。换句话说,法律限制了论域,但论域的所有性质依然存在。
4. `规范化导致系统性能不佳`
规范化意味着给定的编码关系只对应一个逻辑谓词。这在原则上与性能无关,至少没有必然联系。
## 结论
键和规范化的必要性并非关系模型的特有怪癖。它反映了我们正在建模的世界(即我们的论域)中更深层的东西。我们必须无歧义地指称事物,为此,事物必须具有稳定的、可区分的本质。
辨别“国家是什么”或“个体由什么构成”的困难,并非本质不存在的证据,而是发现本质很难的证据。这是一个认识论上的挑战,而非本体论上的缺失。
关系模型并非将人为结构强加于无形的数据之上,而是明确表达了任何关于现实的连贯话语都已预设的前提:世界由具有本质的事物组成,而我们能够认识这些本质。
图1:法国大革命者对圣马丁教堂的破坏
图1:法国大革命者对圣马丁教堂的破坏
相似文章
冗长并非忠实:一个架构论证——推理模型无法进行忠实推理 [D]
本文论证推理模型无法进行忠实推理,因为其推理轨迹与最终答案源于同一操作。文章回应了 Lanham、Turpin 和 Mirzadeh 的批评,并对比了 HRM、TRM、GRAM、AlphaProof 及 Kona/Aleph 等架构谱系。
ORM教会我的:直接学SQL (2014)
作者认为ORM弊大于利,开发者应直接学习SQL,以避免属性蔓延和低效查询等问题。
结构化主键
本文讨论了传统主键设计如何导致表孤立,并介绍了结构化主键作为一种替代方案,以提高SQL查询性能并维护关系完整性。
关系建模与 APL
作者探讨了利用约束逻辑和等式重写规则,将关系建模与 APL 风格的数组语言相结合,并讨论了如何将属性定义为双向推导,而非简单的赋值。
理解的乐趣与力量
对深刻理解代码与系统之乐趣与力量的反思,并警惕过度依赖LLM和捷径会削弱真正的精通。