数据库的主键字段名叫`ID`不香么，为什么非要`table 名+ID`、`table 名缩写+ID`？

@lichao 表加前缀还是有点用的。以前我们用简短的业务单词当表前缀，相同业务的表一搜就出来

id 我是可以接收的，但是写成 ID 我就想骂娘了

1.无论选择哪种方案，都有自己的优缺点。

2.一个团队，人多了，每个人的思路可能会不一样。这种事情，在开发之前，大家商量讨论一下，把规范定下来就 OK 。

都叫 ID 不够明确啊，虽然有些表里纯粹做主键用途的可能不会被用到，但是等你关联多个表之后想要使用他排序的时候。。。

@lichao “t_”的这种是因为还有视图这种东西，为了不搞混加的，现在的项目都不用视图，存储过程了吧

习惯

桌面 App 时期，大多数业务逻辑都使用数据库+存储过程形式实现。复杂过程实现中，数据库表一多，写存储过程时都叫 id 就容易出错，需要指定别名，因此那时一般要求主键使用“表名+id”形式。

现在 WEB App 时代中，大多建议使用程序 ORM 框架来实现类型业务查询与计算，避免过多使用存储过程、视图等技术，就没这项要求了。实际上，新一代的 ORM 框架，比如 Rails 、GORM 推荐表名主键就叫 id 。

用表名做 id，还是有好处的，比如多表关联查询的时候，不需要在去写新的实体去单独映射这个字段

好多数据库 ID 是保留字

直接叫 id 比较好，只作为每行记录技术上的区分
业务唯一键另外定义，比如 user 表 就可以叫 user_id 或者 user_code

@ShangL 你这个问题 根本原因归结于设计表结构的时候“偷懒”，把其他表的 id 作为业务字段使用了。单论 MySQL，id 字段理论上不应该有业务含义

不叫 id 的情况就在于，多表联查时你知道这个 id 是个啥，但规则这东西说白了现在的公司除非有那种非常一板一眼的 pm 给你抠字段名，否则一定是乱丁日 起名，兄弟把自己劝一下，忍一手过去得了。

@b0644170fc 业务模块前缀有区分能力，t_就不行

从 SQL 的角度 foo_id 好点，因为 join 的时候不用专门指定.

从代码的角度 id 好点，代码处理 entity 的时候会简单很多，不需要很复杂的代码或者框架.

其实区别不大，就是感觉 foo_id 有点老气，不过别人让我用我也没啥意见.

个人倾向于直接使用 id，可以避免表名太长时的命名焦虑。

《 sql 反模式》 4.5.1 。一百多楼都没提到？