数据表设计时主键叫做 id 还是 userId 好呢？

[fengsi]

比如一张 User 表，主键命名为 id 还是 userId 好呢？

1. 每张表都叫 id ，而不叫 xxxId,这样即使表名比较复杂也没关系。

2. 用户表跟实体映射时，如果表中是 user_id ，实体变量叫做 userId ，显然更清楚一点。而且也方便一些工具生成代码

还听说了一些其他方案：

1. 固定每张表都设计一个 id, 再根据需要再设计一个 userId ，这种的话按照我的业务来看，这个 id 好像确实比较多余。

请教大家的习惯的方案，目前我的方案是，数据表叫做 id ，实体对象变量叫做 userId 。外键叫做 user_id

另外请教大家：有没有一些实际的设计规范可以参考的呢？

[ysc3839]

id

[ysc3839]

id ，因为一般情况下根据上下文信息就能得知是 user.id 了。变量名也没必要用 userId ，用 user.id 即可，除非是 userId = user.id 这种情况。

[laikick]

规定好就行. 别一下是 id 一下是 userId

[fengsi]

@ysc3839 #2 感谢前辈回复，学到了。我多问一句，变量名我用 userId 的原因是为了返回数据给前端考虑，返回 userId 前端就可以很清楚的这是 user 的 id 了，前辈是推荐直接返回 id 吗？

[ysc3839]

@fengsi 前段也适合上述逻辑，比如是 getUser 的接口，那一般会写成 user = getUser()，那就能用 user.id 。如果是多种数据混合的话，可以看情况选择使用 userId 或者 user: { id }。

[adoal]

表内字段一般没必要带上表名作前缀

[Vegetable]

实践上来看都是 id 。
`user`.`user_id`这种命名方式让我觉得很奇怪且多余

[godleon]

客观评价一下吧，我觉得应该根据业务来说；
以 mysql 为例;
一张表使用 uid mid sid 或者 id 作为主键，其实没什么性能上的区别，哪怕你映射实体不过是一个别名而已，从代码设计上，你用 userId 和 id 我觉得没啥标准的吧；

但是在你的业务，存在拆表 分库分表 分布式等架构，这个时候你每个表都有一个 id 然后再有一个 业务的 uid 或者 mid sid 这类是这个业务的表示， 当你有分布式跨库全局唯一 ID 或者设计行锁 表锁 分布式事务等 这个 id 的存在就有很大意义了；

[ksc010]

一般用 id ，但是 user 这个表比较特殊，习惯用 userid

[9dP06m83vIV00l72]

user.id
order.user_id

[NewMoorj]

我用 user_id ，这样全表命名都比较统一，所有 ID 之前都加命名，方便识别。

[foolishcrab]

显然是 id 好，实体类的字段是不可能脱离主体来使用的，加上 user 并无意义。

延伸一下，有些人喜欢
xxxXxxxxXxxxResponseType.responseStatusType.responseStatusMetaType
而不是
xxxxXxxxResponse.status.meta

前者看着恶心，代码逻辑还没开始写就换行了

[kkwa56188]

大项目, 表多, 关系复杂的, 用 user_id, 参见 数据库老祖宗 Oracle 的 E-business Suite, 或者大型 ERP 顶流 SAP, 的设计实践.
没做过的就不要说了.
小项目 小数据库的, 无所谓 怎么都行.

[hendry]

UID 可以吗不

[neptuno]

我一般用 id ，之前有人跟我说过全部用 id ，联表可能可读性差一点，不过我觉得还行，联表的时候，别名写的清楚一点就好了。

[BeijingBaby]

user.user_id ，这样很蛋疼，不如 user.id

[mwjz]

每一个表都是实体， 用 id 就代表当前实体的主键，规则清晰。 连表外键用 userId ，xxxId, 如果都用 xxxId ，会很疑惑

[wanguorui123]

用 User ID 比较方便，用 ID 比较规范，有时候方便比规范重要

[akira]

按公司定的规范来。。