Jaa*_*rus 8 sql relational-database
关系模型的核心规则之一是元组(行)所需的唯一性:
通过指定包含表的名称,包含列的名称和包含行的主键值,数据库中的每个单独标量值都必须在逻辑上可寻址.
在SQL世界中,这意味着表中永远不会存在两行,所有列值都相等.如果没有有意义的方法来保证唯一性,则可以向表格提供代理键.
当第一个SQL标准发布时,它没有定义这样的限制,从那时起它就像这样.这似乎是所有邪恶的根源.
是否有任何有意义的理由决定采用这种方式？在实际的世界中,没有这种限制可以证明是有用的吗？它是否超过缺点？
简短的回答是 SQL 不是关系型的，SQL DBMS 也不是关系型 DBMS。
重复行是 SQL 数据模型的基本部分，因为 SQL 语言并没有真正尝试实现关系代数。SQL 使用基于包（多集）的代数代替。关系代数中的查询和其他操作的结果是总是具有不同元组的关系，但 SQL DBMS 不能只处理关系。鉴于 SQL 语言的这一基本“特性”，SQL 数据库引擎需要具有处理和存储重复行的机制。
为什么 SQL 是这样设计的？一个原因似乎是关系模型在当时是一个太大的信念飞跃。关系模型是一个远超时代的想法。另一方面，SQL 过去和现在都深深植根于三年前的系统中。
您假设数据库仅用于存储关系数据；这当然不是它们的用途，因为实际考虑总是会获胜。
不需要主键的一个明显示例是某些描述（天气/数据库/其他）的“状态”日志。如果您永远不会从此表中查询单个值，您可能不希望有主键，以避免必须等待插入到键中。如果您有一个用例从该表中获取单个值，那么当然，这将是一个糟糕的解决方案，但有些人只是不需要它。如果绝对有必要，您可以随时添加代理键。
另一个例子是写密集型应用程序需要告诉另一个进程做某事。这个辅助进程每 N 分钟/小时/无论什么时间运行一次。一次性对 N000 万条记录进行重复数据删除比检查表中每次插入的唯一性要快（相信我）。
作为关系数据库出售的产品并不仅仅用作关系数据库。它们被用作日志、键值存储、图形数据库等。它们可能不具有竞争对手的所有功能，但有些具有，而且拥有一个不适合您的关系模型的表通常比创建一个表更简单整个其他数据库并遭受数据传输性能损失。
tl;dr人们在数学上并不完美，因此不会总是使用数学上完美的方法来做某事。委员会是由人组成的，有时可以意识到这一点。