相同的主键是不好的做法吗？答案

【问题标题】：Are identical primary keys bad practice?相同的主键是不好的做法吗？
【发布时间】：2011-11-16 04:11:29
【问题描述】：

我正在尝试创建一个用户可以注册和创建配置文件的站点，因此我在数据库中使用了两个 MySQL 表，例如users 和 user_profile。

users 表有一个名为 auto increment primary key 的 user_id。

user_profile 表具有相同的 primary key，称为 user_id，但它不是 auto increment。

*请参阅注释，了解为什么我有多个表。

当用户注册时，将注册表中的数据插入到用户中，然后将last_insert_id() 输入到user_profile 表的user_id 字段中。我使用事务来确保这种情况总是发生。

我的问题是，这是不好的做法吗？

我是否应该为user_profile 表提供unique auto increment primary key，即使一个用户只能拥有一个个人资料？

也许创建这样的数据库还有其他缺点？

如果有人能解释为什么这是一个问题，或者如果没问题，我将不胜感激，我想确保我的数据库尽可能高效。

注意：我为 user 和 user_profile 使用单独的表，因为 user_profile 包含可能为 null 的字段，并且由于数据显示在 public个人资料。

也许这也是一种不好的做法，应该把它们放在一张桌子上？

【问题讨论】：

标签： php mysql

【解决方案1】：

我发现这是一个很好的方法，如果您使用外键关系并且最好在从用户表中删除用户时级联，我会加分。

将核心用户数据放在一个表中，而将选项配置文件数据放在另一个表中 - 干得好。没有什么比 90% 空值的 50 字段龙式条目更烦人了。

【讨论】：

这并不像你说的那么简单。拥有外键关系意味着在 mysql 上有一个 innodb 存储引擎。从 myisam 切换到 innodb 并不像 ALTER 看起来那么简单。
感谢您的回复，我曾考虑过外键，但看起来我可能更容易忽略它们。不过，我会让他们再看一眼！
@fyr：无论如何我都使用 Innodb 存储引擎，这是事务的要求。
@Alex：last_insert_id() 不需要交易。
@Tomalak：是的，我知道，但我只是想确保在用户尝试注册时始终创建 user_profile，以便在服务器崩溃等情况下节省任何麻烦。

【解决方案2】：

这通常是不受欢迎的，但只要你能提供一对一关系的推理，我相信它没问题。

当我有数百列时使用它们（将它们分成单独的表会更合乎逻辑）或者我需要一个更薄的表来加速全扫描

在你的情况下，我会使用一个表并创建几个视图。

一般来说，单表方法更合乎逻辑、更快、更简单，并且占用的空间更少。

【讨论】：

谢谢你，我原以为它会“皱眉”。我将不得不研究什么是视图，我承认我对 MySQL 的了解还没有达到我想要的水平。当然我不知道 user_profile 表将来会有多大，肯定把它放在一个单独的表中可以避免以后的任何困难吗？
它是唯一不认为这是一个好主意的人......如果你考虑一下它的效率要低得多，因为数据库必须检查外键（假设您正在使用它们）并维护 2 个索引结构。
如果您使用视图来隐藏底层物理结构，您可以在不更改任何代码的情况下从单个表更改为多 1 对 1 结构，只需将 user_profile 视图指向新表
谢谢，这听起来像是一种很有前途的技术，我会使用您的链接并进行研究。
我决定继续购买 Paul DuBois 的 MySQL，我刚刚看到了让我考虑您的答案的视图部分。看起来视图会使编写查询更简单，但是速度或空间带来的任何好处都将是微乎其微的，并且有些人会建议，如果表变得很大（数千行+），视图实际上会降低性能。我可能会坚持 1-1 的关系。

【解决方案3】：

我不认为这是一个坏习惯。有时它非常有用，特别是如果您希望一个类处理身份验证，而不是加载所有配置文件数据。然后，您可以修改身份验证的工作方式、构建 Web 服务等，而无需关心维护有关配置文件信息的数据结构，这些数据结构可能会随着项目的发展而改变。

【讨论】：

【解决方案4】：

这是非常好的做法。

这是编写良好、模块化、规范化关系数据库结构的核心。

【讨论】：