关联唯一ID

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

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

来源

2013-07-01 Killian

谁告诉你，在什么情况下？确实，通常推荐在通过URL传递信息时使用随机的，非顺序的ID，但是如果唯一值不向全世界或最终用户公开，通常是不必要的。换句话说，并不是每个表都需要它。 –

我是在实习中作为迁移项目的一部分。我的导师，如果你在团队中表示每个表都应该有一个ID列，并且PK应该与该ID保持分开。 – Killian

如果PK值没有从外部暴露出来，我没有看到它的价值。出于同样的原因，只有我家的外门有重重的死锁。递增PK列的目的是强制执行唯一性，而且您并不需要_double_唯一性。 –

你的“导师”在某种意义上是正确的。在迁移和BI星形架构DWH中，最好提出一个新的UID。

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

虽然，正如其他人所说，这是没有必要的。在BI环境中加入数据时最佳做法。

希望有所帮助。

来源

2013-07-01 19:30:15 Sev09

好吧，我想我明白这一点。但是如果您打算使用UID将表格与其他表格相关联。什么是阻止匹配或格式的相同问题（除非你有意识地决定将它们全部保留为数字）。另外，如果您可以使用UID关联和识别表中的记录，甚至有PK的意义何在？ – Killian

只有在连接两张带有自己PK的表格时，UID才是必需的。就像加入示例表table_customer_data和table_order_status一样。 Table_customer_data可能具有Cust_Num作为PK，而table_order_status可能具有Order_Num。这些可以是其自己的透视表中的唯一标识符，但可能会在组合数据表中重叠。因此，需要为表中的每条记录创建一个新的PK。 – Sev09

对不起，你又失去了我。 Cust_Num和Order_Num是他们自己的表中的PK。但是因为它们在组合数据表中重叠，所以您需要新表中每个记录的新PK？你为什么要组合这两个表，或者你在谈论像Customer_Order这样的解析表？ – Killian

回答

相关问题