这是一个创建于 2041 天前的主题，其中的信息可能已经有所发展或是发生改变。
吐槽一下，现在这家的公司表结构设计的很蛋疼，只要有下拉框的地方，要同时传 value 和 name 给后端。 例如有一张用户表 User，只要有用到 User 下拉框的页面，保存的时候前端都要把 userId 和 userName 同时传给后端。对应的表同时存 UserId 和 UserName，美其名曰，要 UserName 的时候少连一张表。 有时候一个下拉框可能要传 5 个值给后端，因为这些值不是存在子表，而是用 JSON 字符串存在一个字段里面。 会有公司这样设计表结构？ 不懂是出于什么样的考虑。
 |
1
miao666 2019-04-23 22:40:12 +08:00 via iPhone  1
跟设计关系不大吧？
你传个 id 就行，服务端不能再查一遍？ 要是用户篡改 username 和其他字段的值咋办？ |
 |
2
zhuzhibin 2019-04-23 23:27:35 +08:00 via iPhone
跟后端协商就好 单纯的这种连表查询开销不大的... 即使不连表 服务端也可以根据 id 再去查一遍关联的 name 表 只需要在用户模型简单封装一个关键 username 的方法即可
|
 |
4
AngryMagikarp 2019-04-23 23:29:28 +08:00
你们后端水平不够，没其他原因。
|
|
5
AngryMagikarp 2019-04-23 23:30:08 +08:00
分不分离和数据库设计没有关系。
|
 |
6
DiverRD 2019-04-24 00:13:49 +08:00 via Android 1
我个人主张一般都是前端传给后端越少越好。
|
 |
7
TomVista 2019-04-24 07:59:18 +08:00
前后端都要处理一遍数据,方便对方接收 /取用
|
 |
8
NicholasYX 2019-04-24 08:20:21 +08:00 via iPhone
这跟前后端分离没关系……
|
 |
9
zhady009 2019-04-24 08:44:07 +08:00 via iPhone
userid username 不都是后端在会话里拿就行了吗
|
 |
10
66beta 2019-04-24 08:53:32 +08:00 via Android
让后端再去学学关系数据库原理和 SQL 范式
|
 |
11
jydeng 2019-04-24 09:09:17 +08:00
后端设计有问题，应该一张单独的表来存用户信息，前端只传递 id。
至于性能问题，有很多解决方案。 |
 |
12
wshcdr 2019-04-24 10:55:13 +08:00
这跟前后端分离没关系
|
Select Language