关系模型的core rules之一是元组（行）所需的唯一性：
通过指定包含表的名称，包含列的名称和包含行的主键值，数据库中的每个单独的标量值都必须在逻辑上可寻址。
在SQL世界中，这意味着表中永远不会存在两列都相等的行。如果没有有意义的方法来保证唯一性，则可以向该表提供代理键。
当第一个SQL标准发布时，它没有定义任何此类限制，从那时起就一直如此。这似乎是种种邪恶的根源。
是否有任何有意义的理由决定采用这种方式？在实际世界中，没有这种限制的情况在哪里可以证明是有用的？它胜过弊端吗？
最佳答案
您假设数据库仅用于存储关系数据。这肯定不是它们的用途，因为实际考虑总是会赢的。
一个不需要主键的明显例子是带有某些描述（天气/数据库/其他）的“状态”日志。如果您永远不会从该表中查询单个值，则可能不希望拥有主键，以避免不得不等待插入键中。如果您有用例从该表中选择单个值，那么可以肯定，这将是一个糟糕的解决方案，但有些人根本不需要。如果绝对必要，您以后可以随时添加代理密钥。
另一个例子是写密集型应用程序需要告诉另一个进程做某事。此辅助过程每N分钟/小时/无论运行一次。一次性对N百万个记录进行重复数据删除比检查表中每个插入的唯一性要快得多（请相信我）。
作为关系数据库出售的产品不仅仅用作关系数据库。它们被用作日志，键值存储，图形数据库等。它们可能不具备竞争的所有功能，但有些却具有功能，并且拥有一个不适合您的关系模型的表通常比创建一个表更简单。整个其他数据库并遭受数据传输性能损失。
tl; dr人们在数学上并不完美，因此不会总是使用数学上完美的方法来做某事。委员会由人员组成，有时可以实现。