队伍里的小伙子这样设计表，应该怎么评价

[5sheep]

项目里有几个多对多关系，需要表达到关系数据库。

比如：用户 角色 权限； 用户与角色是多对多关系；角色与权限是多对多关系；

一般人会分别创建 [用户角色表]、[角色权限表]，来存储多对多关系，这个没啥好说的。

现在队伍里一个小伙子嫌麻烦，就创建了一张 [数据关系表]，大致字段有：[第一个 id]，[第二个 id]，[表名]。

大家分析下，这种做法，要如何评价

[pws22]

说实话,如果没有一些关联特殊要求,其实设计一个大表做关联没什么毛病,就是直观看上去不好理解,但是程序逻辑能弄清就行,但是如果关联上有一些额外的字段,说不定过了一段时间再看,都会忘记了当初的设计条件了,看代码也会一脸懵,咋回事,都是反复调用这个大关联表来做操作..不能图一时轻松,还有考虑后期的维护成本和其他后来人的接受程度,选择一个大家都能比较好理解的做法. ps 如果是我组成员做出这样的,限期修改吧.

[murmur]

好家伙，表名直接写到数据里么

[c6h6benzene]

人和程序有一个能跑就行 /doge

[baoshijiagong]

维护性很烂，也没什么好处，比如联表时要写 data_relationship.table_name='user_role' and data_relationship.firstId = user.id, 实际上不存在 user_role 表，所以字段名也让人不明所以，用正常的方式是 user.id = user_role.user_id, 简洁明了。对于使用了某些框架的系统，更是阻碍。

[baoshijiagong]

有这种表的存在，连数据库表的模型图都不能直观画出来。

[kingfalse]

这哥们把 mysql 当 mongo 用了吗这是

[vone]

笑死，那可以把所有表都合并成一个，极为方便。

[way2create]

感觉这样更复杂啊其实

[way2create]

感觉你脸皮没他厚 怼不过他

[rationa1cuzz]

我接受这个项目，小伙是这么建表的：[角色权限 1 表]、[角色权限 2 表]、[角色权限 3 表]、[角色权限 4 表]。。。。

[cnrting]

这不是你该操心的事

[ttyn]

公司流程问题，这样的设计也并非不可以，要结合具体的项目来看，
稍微正规点的应该有个“设计 -> 评审 ”流程
评审通过，出问题大家一起背锅，
评审不通过，打回去修改

[fml87]

典型的眼高手低，场景又不复杂，这样搞只是白白增加维护成本

[intmax2147483647]

你不了解，就别瞎说。🤣

[11232as]

A 多对多 B,B 多对多 C
| B_id | A/C id | A/C 表名|
| --- | --- | --- |
| ... | ... | ... |
虽然有点怪但也没啥问题...

[cszchen]

没看出来哪儿方便了，工作量不仅不会变小，可能还会变大，如果有可能就让他做简单的 curd，或者直接开掉

[redford42]

表设计还是评审一下吧

[JoeBreeze]

团队合作还是需要一些规范的, 他喜欢这样做, 然后其他人也大部分都认同, 打不过就加入吧, 后面有锅给他背就好了

[egfegdfr]

这么搞，在做删除、新增操作的时候，不容易产生死锁吗？ 虽能说 可以通过加索引、或者是分布式锁控制，但是这个设计好几个业务逻辑，感觉这么设计的优点是小于缺点的

[Carlgao]

在多对多中间表里面加表名类型区分，可以减少中间表的数量，这属于常规操作吧。