SQL查询结果中重复的产生与"真重复"的辨识困境

“只要基表没有重复行，重复问题就与我无关”这种想法是错的——即使输入的基表完全 不含重复（比如常用的suppliers-and-parts示例数据库本身没有重复行），同一个查询 问题用不同的SQL表述方式仍然可能在结果里产生带重复度差异的输出，这说明重复行 问题并不局限于基表设计层面，而是贯穿SQL查询执行的整个过程。禁止重复还有一条 [[关系是n维的而非二维的]]视角下的心理学论据：如果把关系类比成”n维空间中若干点 的集合”，重复行在这个类比里完全没有提供任何新信息——它们只是把同一个点重新 画了一遍，除了浪费笔墨没有任何额外价值。更实际的一条论据来自数据完整性：如果 一张表T本身就允许重复，那么就永远无法区分”业务上确实有意义的真重复”（比如同一 供应商真的对同一零件重复发运了两次货）和”纯粹因为数据录入失误产生的重复”（操作 员不小心把同一行输入两遍、或者不小心多敲了一次回车）——一旦两种重复在存储层 面变得不可区分，也就没有任何直接手段能在保留”第1行”的前提下单独删除误录入的 “第2行”，而这恰恰是应该删除的那一行。这个困境反过来印证了[[关系的精确定义与 关系命名之谜]]背后信息原理的立场：允许重复的设计天生就在制造无法挽回的信息 歧义。