数据库中 id 字段存在的必要性

[qyz0123321]

在公司设计数据库的时候，有人提出来了在设计数据库的时候直接使用中文名字作为主键，表之间的关系也直接用中文名字作为主键（中文名字不重复）。
这样做的好处当然是数据库方便易读，易于理解，但是这样做势必会保证搜索速度下降（我是这么认为的），增大数据库的大小。
但是不知道现在的 mysql ， mssql 数据库对中文做的优化能不能抵消搜索的劣势？有没有使用中文作为主键的场景？
刚刚毕业学生，求轻喷。。

[jianyunet]

@qyz0123321 你考虑的问题已经有过很多讨论了，典型的逻辑主键和物理主键问题

用含有物理意义的字段做主键，需求变更会比较难办，或者举个简单的例子，楼上也提到过了，你能保证身份证真的是唯一的吗？人家就有发错的怎么办？

[kiwi95]

id 做主键比较好，中文名加个唯一约束，加索引吧。 id 做主键有很多方便的地方

[winnie2012]

https://ruby-china.org/topics/26352

[qyz0123321]

@jianyunet 明白了，谢谢

[glasslion]

很多 ORM 在实现上就要求数字自增主键

[aspirin2d]

mongodb 表示，根本没得选， id 就是文件名 -_-P

[karloku]

id 最好是一个 和业务无关, 不会重复的数字. 至于是不是自增整型这不重要.
id 的意义就在于无论业务如何变化, 记录的内容如何变化, 都可以唯一标识这一条记录.

至于楼主最后说的被枚举, 这个不需要担心. 现在大家分布式系统用的多, id 的生成规则也会比较复杂. 像是分布式数据库常用的机器 hash+进程 hash+时间戳 hash+本地自增序列拼出 32 位乃至 64 位整型, 这个要枚举先过 ddos 防护这一关

[Youen]

我觉得这个问题和 id vs guid 作为主键的问题有些相似。

[LPeJuN6lLsS9]

@glasslion 你说的“很多”有哪些？很多 ORM 没有你说的要求，比如 django 自带的和 SQLAlchemy ，小的有 peewee 。

我有见过这种情况：只加了一个代理 PK ，而对于真正的 key 却连 UNIQUE 都不加（在这里是一个类似 UUID 的 varchar ）

[msg7086]

@karloku 一直到 27 楼才终于有人点出这句话我也是醉了。

主键的作用就是永久有效地标示这唯一一条记录，最好与业务无关。

@hantsuki 类似 UUID 的 varchar 其实加不加 UNIQUE 没区别。 UUID 本身撞 ID 的几率就小得不行[1]，不需要考虑唯一性。

[1]: https://zh.wikipedia.org/wiki/通用唯一识别码#.E9.9A.A8.E6.A9.9FUUID.E7.9A.84.E9.87.8D.E8.A4.87.E6.A9.9F.E7.8E.87

[Cloudee]

作为索引的话，中文谁不会慢的，但是， varchar 会慢...考虑到大部分情况中文都是放在 varchar 字段里的，很多人就觉得中文慢了

[LPeJuN6lLsS9]

@msg7086 “总之先来个 id ”在生产时确实很通用，不得不承认……

如果不用关系数据库提供的其他方法保证数据的完整性，这个 id 其实就是个 rownumber 。如果其他地方都不会用 id 引用这条记录，那不如让数据库自己隐式加上

[msg7086]

@hantsuki 感觉你说反了。
既然总要有个 ID ，那不如你自己加上。免得以后业务需要 ID 的时候再去加一个。
同时自己加的 ID 还可以跨平台跨环境，不用考虑数据库之间的不同实现。

[chenjf2k]

建议主键命名：表名+ID