关联唯一 ID答案

【问题标题】：Relating Unique ID关联唯一 ID
【发布时间】：2013-07-01 19:18:14
【问题描述】：

只是一个非常快速的问题，我似乎无法找到答案。我正在制作这些表格，并且有人告诉我，每个表格都需要有某种形式的随机唯一 ID，它与 PK 是分开的。我的问题是，我是否可以以与 PK/FK 相同的方式将两个表与 UID/FK 关联起来。

这是不好的做法吗？有什么优点/缺点？

【问题讨论】：

谁告诉你的，在什么情况下？例如，确实经常建议在通过 URL 传递信息时使用随机的、非顺序的 ID，但如果唯一值不向世界或最终用户公开，则通常不需要。换句话说，并不是每张桌子都需要它。
我在实习期间将其作为迁移项目的一部分。如果您愿意，我的导师说每个表都应该有一个 ID 列，并且 PK 应该与该 ID 分开。
如果 PK 值没有对外暴露，我看不出它有多大价值。出于同样的原因，只有我家的外门有很重的插销锁。增加 PK 列的目的是强制唯一性，您实际上并不需要 double 唯一性。
因此，建议在所有表中同时拥有主键（顺序生成或自然键？）和（随机生成）唯一键？
这就像有一张员工表。 SSN是主键，然后会有另一个随机唯一ID

【解决方案1】：

你的“导师”在某种意义上是对的。在迁移和 BI 星型模式 DWH 中，最好提供一个新的 UID。

原因：当将相似的表连接在一起时，可能会有匹配或不同格式的主键。

不过，正如其他人所说，没有必要。在 BI 环境中加入数据时的最佳实践。

希望对您有所帮助。

【讨论】：

好吧，我想我明白了。但是，如果您打算使用 UID 将表相互关联。什么可以阻止匹配或格式出现相同的问题（除非您有意识地决定将它们全部保留为一个数字）。另外，如果你可以使用 UID 来关联和识别表中的记录，那么即使有 PK 又有什么意义呢？
UID 仅在使用它们自己的 PK 连接两个表时才需要。就像您要加入示例表 table_customer_data 和 table_order_status 一样。 Table_customer_data 可能有 Cust_Num 作为 PK 并且 table_order_status 可能有 Order_Num。这些可能是它们自己的透视表中的唯一标识符，但可能在组合数据表中重叠。因此，需要为表中的每条记录创建一个新的 PK。
对不起，你又把我弄丢了。 Cust_Num 和 Order_Num 是各自表中的 PK。但是因为它们在组合数据表中重叠，您需要为新表中的每条记录一个新的 PK 吗？你为什么要组合这两个表，或者你在谈论像 Customer_Order 这样的解析表？
是的，一个解析表。否则，就像我提到的那样，没有必要。