你们公司前后端分离都是怎么设计数据库表的？

[jokyme]

吐槽一下，现在这家的公司表结构设计的很蛋疼，只要有下拉框的地方，要同时传 value 和 name 给后端。 例如有一张用户表 User，只要有用到 User 下拉框的页面，保存的时候前端都要把 userId 和 userName 同时传给后端。对应的表同时存 UserId 和 UserName，美其名曰，要 UserName 的时候少连一张表。 有时候一个下拉框可能要传 5 个值给后端，因为这些值不是存在子表，而是用 JSON 字符串存在一个字段里面。 会有公司这样设计表结构？ 不懂是出于什么样的考虑。

[miao666]

跟设计关系不大吧？
你传个 id 就行，服务端不能再查一遍？
要是用户篡改 username 和其他字段的值咋办？

[zhuzhibin]

跟后端协商就好 单纯的这种连表查询开销不大的... 即使不连表 服务端也可以根据 id 再去查一遍关联的 name 表 只需要在用户模型简单封装一个关键 username 的方法即可

[zhuzhibin]

@zhuzhibin 关联 打错了

[AngryMagikarp]

你们后端水平不够，没其他原因。

[AngryMagikarp]

分不分离和数据库设计没有关系。

[DiverRD]

我个人主张一般都是前端传给后端越少越好。

[TomVista]

前后端都要处理一遍数据,方便对方接收 /取用

[NicholasYX]

这跟前后端分离没关系……

[zhady009]

userid username 不都是后端在会话里拿就行了吗

[66beta]

让后端再去学学关系数据库原理和 SQL 范式

[jydeng]

后端设计有问题，应该一张单独的表来存用户信息，前端只传递 id。
至于性能问题，有很多解决方案。

[wshcdr]

这跟前后端分离没关系

[jokyme]

@miao666 之前评审数据库表结构的时候，貌似是说为了少联一张表。后面干脆很多表都设计成了这种结构。所以造成了本来应该后端去联表查的数据，变成了在新增的时候，从前端传给后端。

[jokyme]

@zhuzhibin emmm...... 系统已经开发完了，现在再协商改表结构后端也不会同意，改动量太大。