是否有支持“全代理”的规范来源？

Question

背景

这 “所有 PK 都必须是代理” 方法不存在于 科德的关系模型 或任何 SQL标准 （ANSI、ISO 或其他）。

规范书籍似乎也规避了这一限制。

Oracle自己的数据字典方案在某些表中使用自然键，在其他表中使用代理键。我提到这一点是因为这些人必须对 RDBMS 设计略知一二。

聚二苯醚 （专业石油数据管理协会）推荐同样的规范书籍：

在以下情况下使用代理键作为主键：

1. 没有自然键或业务键
2. 自然或商业密钥不好（经常改变）
3. 插入记录时自然密钥或业务密钥的值未知
4. 多列自然键（通常是几个 FK ）超过三列，这使得连接过于冗长。

另外，我还没有找到说明自然键需要不可变的规范来源。 我发现它们需要非常稳定，即只在极少数情况下需要改变（如果有的话）。

我提到 PPDM 是因为这些人也必须对 RDBMS 设计略知一二。

“全代理”方法的起源似乎来​​自一些 ORM 框架的建议。

确实，该方法允许 快速数据库建模 不必做太多的业务分析，但以牺牲可维护性和 可读性 SQL 代码。对未来可能发生或可能不会发生的事情做了很多预见（自然的 PK 发生了变化，因此我们将不得不使用 RDBMS 级联更新功能），但牺牲了日常任务，例如必须在每个中加入更多表。查询并且必须编写在数据库之间导入数据的代码，这是一个非常简单的过程（因为需要避免 PK 冲突并且必须事先创建阶段/等价表）。

另一个论点是基于整数的索引更快，但这必须得到基准测试的支持。显然，长的、变化的 varchars 不利于 PK。但是基于短的、固定长度的 varchar 的索引几乎和整数一样快。

问题

- 是否有任何规范来源支持“all-PK-must-be-surrogates”方法？

- Codd 的关系模型是否已被更新的关系模型取代？

Answer 1

“所有PK都是代理人”根本不是一个非常好的策略，而且 当然不是你可能找到的“权威”来源.

首先思考一下在这种情况下“主键”是什么意思。在关系模型中，不存在“主”键——这意味着没有一个键与同一表中的任何其他键根本不同。原则上，关系数据库中的所有键都可以而且确实享有相同的地位并具有相同的特性和功能，除非数据库设计者另有选择。因此，在具有多个键的表中挑选出任何一个键本质上是任意的（这是 E.F.Codd 使用的词）、主观的和纯粹心理的（Codd 的同事和合作者 Chris Date 的观点）。除非解释了“主”键和任何其他键之间的区别，否则断言这样的键“应该”或“必须”是任何东西都是毫无意义且毫无价值的。

其次，这个论点与索引关系不大，索引是一种物理存储功能。密钥是一个逻辑问题，而不是物理问题，并且没有绝对的理由假设“主”密钥的存储考虑因素与其他密钥有任何不同或应该有任何不同（请参阅上一段）。我们可以合理地假设，无论使用什么存储结构，存储开销在某种程度上都会是 更大 使用代理键比没有这样的键好，但一如既往，这里最好的答案是“这取决于”。存储决策应根据具体情况做出，一揽子规则几乎没有什么帮助。

第三，从一个 逻辑的 从角度来看，代理键的绝对要求没有多大意义。无论有或没有代理，对自然键的要求完全相同。需要在话语领域（即，与自然密钥（AKA“业务密钥”、“域密钥”）是相同的。是的，密钥可能需要更新，但这有时就是事情的本质。添加代理本身并不一定会使关键更新更容易处理，有时甚至会使更新变得更困难。

Answer 2

主键和外键 不一定是可读的。 它们的目的是维护数据库的内部关系结构，而不是供人类读取。

当然，如果有一个合适的自然键 绝不 改变（我声称这些像母鸡的牙齿或四叶草一样罕见，但是......），你可以使用它，并且一些客户会将其作为他们的要求之一。

但是，为什么要给数据库系统增加额外的复杂性，却几乎没有什么明显的好处呢？主代理键是系统生成的，保证是唯一的，保证永远不会改变，并且对于所有表来说都是相同的数据类型。他们在任何情况下都会有同样可靠的行为。

如果您正在寻找支持这种实践的规范资源，您将找不到。 在过道的另一边，也有同样多的设计师会恶意地捍卫他们使用带有聚集索引的自然复合键作为主键，并且所有规范资源都说这是设计师的选择。

也可以看看
http://en.wikipedia.org/wiki/Surrogate_key