msql建表规约，为什么id为主键，当id为自增主键时，为什么不用更具业务名字的id，比如user_id

[jiandanfeng]

规约原文

【强制】 表必备三字段： id， create_time， update_time。

问题描述

当需要关联查询出两张表时，select A.id,B.id 这时候区分不开id是哪张表的，还要自己设置别名区分；当作为外键关联时，如果id是业务id，也可以直接采用using(业务id).

修改建议

建议采用更有意义的业务id，比如bug_id、user_id

[Allen3500]

使用无意义 ID 的主要目的就是利用它的唯一性保证对象的标识符不会发生冲突，无意义 ID 的唯一作用就是保证唯一性，这能帮助我们避免业务字段可能存在潜在冲突的可能，这也提示我们想要使用联合字段构成主键时一定要深思熟虑。

[jiandanfeng]

使用无意义 ID 的主要目的就是利用它的唯一性保证对象的标识符不会发生冲突，无意义 ID 的唯一作用就是保证唯一性，这能帮助我们避免业务字段可能存在潜在冲突的可能，这也提示我们想要使用联合字段构成主键时一定要深思熟虑。

谢谢回答，但是我所说的业务id，其实也是无意义的id，是数据库自增的，更多的只是想表达id字段的取名而已，取比较有意义的名字，会方便操作。

[zqq90]

个人观点是, 通常情况下, 不要对 属性进行 重复表意 比如:

user {
  id
  name
  age
}

但这并不意味着任何地方都不需要这个所谓的 "前缀", 比如:

app {
  id
  user_id
}

其中 id 自然是 app.id, user_id 自然是代表了一个 user.id

但这并不是一个好例子, 再进一步讲, user_id 也非常不恰当

回过头来看, bug_id user_id 真的就是 "业务id" 吗? 顶多能体现这个字段的 "类型" 罢了

其中, user_id 创建人？负责人？还是开发者？ 不如改成更明确的 owner_id

app {
  id
  owner_id
}

会更加合适,

[jiandanfeng]

当使用有意义的something_id，对于pk和fk关联确实更方便，但java开发手册中有个强制规定： 【强制】 不得使用外键与级联， 一切外键概念必须在应用层解决。 所以pk和fk的关联优势没有了，所以手册主键是id，如果没有该强制规定，id和something_id都可以，都有自己的优缺点。 Naming primary keys "id" vs "something_id" in SQL