数据库设计问题请教：比如 item 表里要表示所属的用户，是直接存 username，还是存 userid，然后查询时候再根据 userid 去查 username，返回给前端？

[zxCoder]

username userid 都是唯一的

我觉得既然 username 也是唯一的，那直接存 username 也是可以的，如果以后还要在 item 这里展示用户的其他字段，也可以用 username 查询得到

[JasonLaw]

id 是没有业务含义的，而 name 是有业务含义的。

[GM]

强烈建议所有关联字段都用 ID 来关联

[ali727]

肯定是 userid 啊，username 有可能修改的。

[iseki]

使用不会改的唯一标识做外键。查询可以想办法优化，但是我看好多不习惯使用外键的，一旦遇到数据变化，脏数据够喝一壶的。

[shyangs]

哪天產品拍腦袋, 說 username 要可以讓用戶自由改, 你要學貼吧在 username 裡加各種符號避免重複?

[512357301]

userid 是否重复是你能决定的，username 是否重复你决定不了。
id 就好像身份证，绝对不重复，而且一般不在前端展示，员工和领导都看不到，也就不会提出质疑。
username 一旦领导发话，就是可以改成一模一样的，你所谓的 username 不重复一般是指的重名的往后面加 01 02 之类的，但是这种太不可控了

[securityCoding]

id

[maplerecall]

id，除了楼上说的那些，如果 username 还允许 emoji 等的特殊字符，那在一些地方还可能得额外折腾…

@iseki 尽量避免使用数据库（尤其是 mysql ）提供的外键是整个业界都比较通用的做法，因为在实际工程中很容易造成操作放大，增加服务器负担，而且十分不利于水平扩展。所以对稍大一些的项目来说一般都使用逻辑外键，即在应用层去保证数据一致性，虽然增加了一些开发成本和难道，但带来的收益是十分值得的。

[JasonLaw]

@maplerecall #8 可以具体描述一下“ 很容易造成操作放大，增加服务器负担，而且十分不利于水平扩展”吗？

[Jooooooooo]

用 id

[iseki]

@maplerecall 用外键不代表一定要 cascade，需要 cascade 的你不用外键一样要手动 cascade，而这种情况大多时候就是最糟糕的设计——真有自信自己写的代码比数据库系统的要好吗？
外键可以很强地保证一致性，也确实会带来一些问题，比如导入导出数据时会变得麻烦，但是这问题我觉得不大。

[iseki]

当然工程有工程的特点，到现在还有一堆人用 mysql 老版本，这不是外键的问题，也不是 mysql 的问题，是那些人那些旧软件的问题。

[Kilerd]

都 2021 年了，还有人说数据库外键是个坏东西啊🤔。
想想你辣鸡同事手动塞的一个坏数据，然后你就被 qa 找了。
想想你写代码忘了写事务，数据完整性炸了

[CEBBCAT]

ID，关系表的关系需要用主键来关联，即使 UserName 不会重复，那取用户其他信息的时候，要通过 UserName 去取生日、住址吗？

[dallaslu]

Email 也是唯一的，怎么不直接用 Email 呢？

[akira]

userid 和 username 都存
以后如果允许修改 username，就再弄个逻辑去根据 userid 更新 username 就可以了
另外 userid 切记切记不要用自增来做