在数据库设计中使用唯一键作为外键好吗？答案

【问题标题】：is it good to have unique key as foreign key in database designing?在数据库设计中使用唯一键作为外键好吗？
【发布时间】：2016-06-27 23:27:42
【问题描述】：

我正在创建用户管理数据库架构。我正在使用 Postgresql 作为数据库。以下是我的方法。如果我使用这种结构，请建议是否存在任何性能问题。

要求：

方法：

我使用pseudo_encrypt() 作为唯一的user_id（BIGINT 或BIGSERIAL），所以没有人可以猜到其他ID。例如：3898573529235304961
在另一个表中使用 user_id 作为外键。我没有使用用户表的主键作为外键。

有什么建议吗？

【问题讨论】：

如果您在这里没有任何吸引力，请考虑 dba.stackexchange.com
考虑使用 xtea 而不是 pseudo_encrypt() 以获得不可猜测的 64 位密钥。
如果用户可以通过猜测的 ID 访问，那么你有问题
有安全措施来授权用户防止被猜测的ID访问，这不是本文的内容。如果我们公开/使用任何 3rd 方服务，则有必要在 REST 世界中向消费者公开唯一密钥。例如，尝试在developers.google.com/oauthplayground 上使用任何API，您可以看到googleapis.com/oauth2/v2/userinfo 正在返回类似于此响应的用户信息对象{“name”：“AMREESH”，“id”：“117344186683399370163”}。我说的是这个Id。
为什么在表User 中同时需要id 和user_id？仅使用user_id。

【解决方案1】：

在自然主键与代理主键的问题上，您在这里涉足了激烈的战争领域。我同意你的观点，经常使用唯一键作为外键，并指定自然主键。在 PostgreSQL 上这是安全的（但在 MySQL 或 MS SQL 上这将是一个坏习惯）。

在 PostgreSQL 中，主键和唯一约束之间的唯一区别是：

实际上，如果您有一个定义为NOT NULL UNIQUE 的表，则它与单个主键几乎相同。

在其他 dbs 上，表结构通常针对主键查找进行了优化，这就是为什么这是一个问题，并且可能有一些工具不喜欢它，但这些问题本身是 db 设计领域之外的问题。

你最好使用普通的连续剧并拥有真正的访问控制，而不是试图在默默无闻的基础上构建东西。然而，模糊控制可能会表现得更差，而且安全性不如仅仅做正确的事情。

【讨论】：

谢谢克里斯。我将使用串行。可以吗，如果我将它增加一些随机值，比如mysql中的自动增量457？在这种情况下，id 将类似于 1、458、915。这些 id 将是不可猜测的。虽然它会增加我的数据库的页面大小。建议？