sql - 我们是否应该将代理键与自然键(唯一索引均值)结合起来以提高可读性和简单的查询选择？

Question

编辑:目前我将保持问题开放。得到一个非常粗略的答案。
很快，这是一个架构


问这个问题是因为 从这个话题 https://www.sisense.com/blog/when-and-how-to-use-surrogate-keys/

Combining Natural and Surrogate Keys Certain business scenarios mightrequire keeping the natural key intact as a means for users tointeract with the database. In these cases …

If a natural key is recommended, use a surrogate key field as theprimary key, and a natural key as a foreign key. While users mayinteract with the natural key, the database can still have surrogatekeys outside of the users’ view, with no interruption to userexperience.

If a natural key must be used without an additionalsurrogate key, be sure to combine it with a surrogate key element. Inour financial database example, Expense Reports (ER-123) have anatural key is used in conjunction with a surrogate sequential key.This format prevents many of the natural key side effects listedabove.

我真的发现也许可以解决我的问题。因为怕代理键。但是 XPO 和 ORM 提供程序支持代理键 (100%)。不像复合键。在许多文章中将其描述为新数据库设计中的一个错误。
Surrogate Key vs Natural Key for EF
Surrogate vs. natural/business keys
还有很多关于这方面的文章。这不是这里的情况。我在说 组合或使用代理键并添加自然键(仅作为索引或唯一索引而不是 PK)
现在回到上面的架构和上面谈论结合两者的主题。我有一个有代理键 Oid 的分支，所有表都有 Oid 作为代理键。我也有自然键，例如(BranchID)，

分支表有 ( Oid[surrogate] , BranchID[Natural Key - Unique Index not PK]

InvTransHed 有 ( Oid[Surrogate] , itd_brn, itd_type, ith_num) 作为自然键(我的意思是唯一索引)

InvTransDet 有 ( Oid[Surrogate] , itd_brm, itd_typ, itd_num, itd_lne 作为自然键 [唯一索引])

我实际上所做的是将所有代理键 Oid 与其外键端联系起来。例如:
Branch.Oid 与 InvTransHed.BranchSKey 关联 [Skey = 代理键]
为什么我需要将 Surrgoate Key 与 Natural Key(作为唯一索引)结合起来？

使用 JOIN 轻松创建报告(直接使用 InvTransDet 分支，无需移动到 InvTransHed)。

技术支持的可读性。无需关心代理键即可轻松进行任何连接。或链接到父表直到达到我们需要的。

易于理解和 ORM 提供者(肯定 100% 友好)

这是一个让我大吃一惊的问题:

我应该只将代理键与他们的另一侧外键联系起来吗？或者我还必须将自然索引链接到它们的自然键。 Branch.BranchID => InvTransHed.ith_brn ?

关于命名对方 FK。 Branch.Oid 代理链接与 InvTransHed.BranchSkey。在这里命名对于可读性是否重要？

请指导我(标题=问题)。

Answer 1

像 PK 和 FK 这样的约束是我们记录和强制执行数据库参照完整性的主要机制。

We can't rely on documentation and data schema naming conventions alone to explain to developers and users how to interpret the data. The whole point around using an RDBM is to maintain referential integrity. Referential and any check constraints form the basis of "truth" about the rules that must be adhered to when inserting data into the database.

您已经正确地指出您想要强制执行 FK 和自然代理键组合的唯一性，因此这主要是一个约束。
如果约束的存在没有问题，那么我们只需要考虑索引。

Unique Constraint vs Unique Index
唯一约束也不必与唯一索引配对，但是对于开发人员的发现，如果您也将其定义为索引，则它只是更多的文档或至少更容易发现。

当或如果性能成为问题，您可能会更改索引的唯一性或将其完全删除，但是在这种情况下您总是希望维护唯一性约束以确保数据的完整性。

虽然不是必需的，但一致的命名约定有助于提高数据模式的可读性并解释结构的意图，但一致性是关键，但第一次违反约定时，读者现在必须怀疑或再次猜测所有先前的假设.

For this reason, if conventions might be questioned, existence of constraints will always provide a definitive answer.

您使用的实际命名约定成为设计者的个人偏好。我用 Id作为PK和 {tablename}Id作为 FK。当链接不明确时，例如一个表对自身有 FK，或同一个表有多个 FK，那么我用描述关系的名词或动词作为列的前缀: CreatedBy_UserId对比 ModifiedBy_UserId我觉得这个约定适合于可读和自然的 SQL 和 C# 语法。

SELECT ID, Description, Modified, ModifiedBy.Name
FROM Product
INNER JOIN User [ModifiedBy] ON Product.ModifiedBy_UserId = ModifiedBy.Id

按照惯例，我知道PK总是 Id , 所以无论在哪里使用它，你都可以假设它是关系的主要终点。