需要高级帮助来验证我对关系数据库设计中代理键的理解答案

【问题标题】：Need senior help to verify my understanding about Surrogate key in relational database design需要高级帮助来验证我对关系数据库设计中代理键的理解
【发布时间】：2015-12-02 13:47:08
【问题描述】：

我想知道我对代理键的理解是否正确。

例如：

以下是我的示例数据库设计

Customers Table

| id(PK) |  Name   |    Age       |   
|  1     |  John   |  34          |
|  2     |  Doe    |  30          | 

QrCodes Table
| id(PK) |  QRcode | Tracking No. | CustomerID (FK)
|  1     |  QR123  |  TR901111    |   1
|  2     |  QR345  |  TR902222    |   2


Redemptions Table
| id(PK) | Name          | Tracking No. | CustomerID(FK)
|  1     |  Redemption 1 |   TR901111   |  1
|  2     |  Redemption 2 |   TR902222   |  2
|  3     |  Rdemption  3 |   TR902222   |  2

如您所见，我有两个 Tracking No. 列，一个用于 qrcodes 表，一个用于兑换表。因此，我可以进行查询，例如通过不跟踪来查找所有二维码和兑换。

Tracking No. 列是否可以归类为代理键？还是不正确？

【问题讨论】：

没有。假设跟踪号是唯一且永久的，则在 QrCodes 表中，id 列是代理项，而跟踪号是。是唯一的 [自然] 键
外键应始终引用主键
好吧，我想我差不多明白了，所以跟踪号列是业务键（非唯一），自动递增（MYSQL db）ID 列是代理/主键。对吗？
如果跟踪编号是唯一且永久的（从某种意义上说，它唯一地标识正在跟踪的任何内容，并且不会在以后重新用于跟踪其他内容或删除 - 根据草莓的原始评论）那么这是正确的。
请理解，最好也描述您在此处建模的现实。从这个有限的数据集中推断很容易导致错误的假设。查看本文第一段，看看代理键和自然键（两者都可以是主键）的区别：decipherinfosys.wordpress.com/2007/02/01/…

标签： mysql sql database relationship

【解决方案1】：

在 cmets 中有点混乱，但它们基本上是正确的（所有人都在上升）。您需要做的是从 Redemptions 中删除 TrackingId，并将 QrCodeId 作为 FK 添加到 QrCode 表中。

如果每个 QrCode 都有一个唯一的 TrackingId（我认为是这种情况），那么它应该有一个唯一索引，但 PK 是 Id。但是，如果不了解您正在建模的内容，就很难说清楚。

【讨论】：