数据库的主键字段名叫`ID`不香么，为什么非要`table 名+ID`、`table 名缩写+ID`？
luxinfl · 2020-09-22 15:53:08 +08:00 · 14018 次点击这是一个创建于 1512 天前的主题，其中的信息可能已经有所发展或是发生改变。
大佬们的主键字段名是怎么定义的？难道不叫 ID 还会有什么好处么？？
第 1 条附言 · 2020-09-22 17:59:08 +08:00
但是我们好像从来不用 id 当查询条件和关联条件，我们一般都是有个某个 code 字段，带有日期、业务的标识号当关联。所以 ID 就叫 ID 好了。有些时候，想查某个表最新的一条数据，我一般都是 select * from xxx order by id desc limit 1，结果就是 id 不存在。。。。
 |
101
b0644170fc 2020-09-23 13:46:42 +08:00
@lichao 表加前缀还是有点用的。以前我们用简短的业务单词当表前缀，相同业务的表一搜就出来
|
 |
102
chenzheyu 2020-09-23 14:01:21 +08:00  2
id 我是可以接收的，但是写成 ID 我就想骂娘了
|
 |
103
laminux29 2020-09-23 14:16:33 +08:00
1.无论选择哪种方案，都有自己的优缺点。
2.一个团队，人多了，每个人的思路可能会不一样。这种事情，在开发之前，大家商量讨论一下，把规范定下来就 OK 。 |
 |
104
foxni 2020-09-23 14:43:45 +08:00
都叫 ID 不够明确啊，虽然有些表里纯粹做主键用途的可能不会被用到，但是等你关联多个表之后想要使用他排序的时候。。。
|
 |
106
wupher 2020-09-23 15:00:05 +08:00
习惯
桌面 App 时期，大多数业务逻辑都使用数据库+存储过程形式实现。复杂过程实现中，数据库表一多，写存储过程时都叫 id 就容易出错，需要指定别名，因此那时一般要求主键使用“表名+id”形式。 现在 WEB App 时代中，大多建议使用程序 ORM 框架来实现类型业务查询与计算，避免过多使用存储过程、视图等技术，就没这项要求了。实际上，新一代的 ORM 框架，比如 Rails 、GORM 推荐表名主键就叫 id 。 |
 |
107
ShangL 2020-09-23 15:27:30 +08:00
用表名做 id，还是有好处的，比如多表关联查询的时候，不需要在去写新的实体去单独映射这个字段
|
 |
108
zwj2885 2020-09-23 15:29:44 +08:00
好多数据库 ID 是保留字
|
 |
109
KarlChen2015 2020-09-23 15:48:18 +08:00
直接叫 id 比较好，只作为每行记录技术上的区分
业务唯一键另外定义，比如 user 表 就可以叫 user_id 或者 user_code |
|
110
KarlChen2015 2020-09-23 15:50:13 +08:00
@ShangL 你这个问题 根本原因归结于设计表结构的时候“偷懒”，把其他表的 id 作为业务字段使用了。单论 MySQL，id 字段理论上不应该有业务含义
|
 |
111
fatcube404 2020-09-23 16:01:56 +08:00
不叫 id 的情况就在于，多表联查时你知道这个 id 是个啥，但规则这东西说白了现在的公司除非有那种非常一板一眼的 pm 给你抠字段名，否则一定是乱丁日 起名，兄弟把自己劝一下，忍一手过去得了。
|
 |
112
MarioLuo 2020-09-23 16:36:29 +08:00 via Android
@b0644170fc 业务模块前缀有区分能力，t_就不行
|
 |
113
namelosw 2020-09-23 20:53:52 +08:00 via iPhone
从 SQL 的角度 foo_id 好点，因为 join 的时候不用专门指定.
从代码的角度 id 好点，代码处理 entity 的时候会简单很多，不需要很复杂的代码或者框架. 其实区别不大，就是感觉 foo_id 有点老气，不过别人让我用我也没啥意见. |
 |
114
CasualYours 2020-09-24 09:33:25 +08:00
个人倾向于直接使用 id，可以避免表名太长时的命名焦虑。
|
 |
115
aguesuka 2020-10-01 16:13:10 +08:00 via Android
《 sql 反模式》 4.5.1 。一百多楼都没提到？
|
Select Language