这是一个创建于 1214 天前的主题，其中的信息可能已经有所发展或是发生改变。
项目里有几个多对多关系，需要表达到关系数据库。
比如：用户 角色 权限； 用户与角色是多对多关系；角色与权限是多对多关系；
一般人会分别创建 [用户角色表]、[角色权限表]，来存储多对多关系，这个没啥好说的。
现在队伍里一个小伙子嫌麻烦，就创建了一张 [数据关系表]，大致字段有：[第一个 id]，[第二个 id]，[表名]。
大家分析下，这种做法，要如何评价
第 1 条附言 · 2021-08-27 12:29:21 +08:00
这个小伙子建了四个模型：用户、角色、权限、数据关系。
我是兼着负责这个项目的技术的，过来时项目已经开发了一段时间了
，小伙子写的是整个平台的基础功能，我很想让小伙子按着常规方法来做
但是小伙不直接归我管，只能讲道理，但是又没有必杀的理由
毕竟这样做功能也能正常跑，给领导演示肯定没问题
之类的问题很多，小伙子的台词是“你不了解，就别瞎说”。
无言反驳，我也无法去证明我是不是了解。
很是苦恼啊。
我是兼着负责这个项目的技术的，过来时项目已经开发了一段时间了
，小伙子写的是整个平台的基础功能，我很想让小伙子按着常规方法来做
但是小伙不直接归我管，只能讲道理，但是又没有必杀的理由
毕竟这样做功能也能正常跑，给领导演示肯定没问题
之类的问题很多，小伙子的台词是“你不了解，就别瞎说”。
无言反驳，我也无法去证明我是不是了解。
很是苦恼啊。
 |
101
MineDog 2021-08-30 20:09:30 +08:00
就是多了一张关系表，感觉没啥难理解，如果每个表的 id 类型都一致，也不是不可以
|
 |
103
ainimuyan 2021-08-30 23:31:27 +08:00
阿里一哥们来了每个表留一个 extra_data varchar(2048) 字段，我直呼牛逼
|
 |
104
Akiya 2021-08-31 14:40:51 +08:00
他这个相当于把边都存在一张表里面了
你需要的是一个 Graph Database |
 |
105
Tinyang 2021-08-31 16:04:34 +08:00  1
这个在数据量小的情况下可以这么设计。但是如果数据关系表变得很大的时候，后面会很麻烦，很难拆开。别问我怎么知道的，我们现在有一张 14 亿左右的关系表（杂糅了很多关系在里面）
|
 |
106
Casbin 2021-09-02 21:55:41 +08:00
|
Select Language