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

[5sheep]

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

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

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

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

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

[drinke9]

这种设计模式，laravel 框架中的一个权限包就是这种结构，`laravel-permission`

[timethinker]

看场景吧，一般角色对权限的是配置数据，数据量不大可以做缓存，更新的情况也比较少。甚至可以把角色对权限的这个关系直接通过配置文件存储起来，都不用存数据库。

而用户对角色的这部分数据是动态数据表，适合放到数据库中。话说回来，量变导致质变，不同的量级有不同的做法，条条大路通罗马。有规范的按照规范执行，没有的话按照简单的来做就行了，在没有规范的前提下就不要苛求太多。

[0o0o0o0]

关键是这逻辑是怎么想出来的，正常人第一次设计都会去网上搜索一下经验或者规范吧，所以说这是自己发明的神奇设计方法吗哈哈哈

[charseer]

一些参数表这样设计没啥问题，很好用的

[Muyiafan]

表中表中表中表中表中表

[superrichman]

@baoshijiagong 怕模型图最后画出来是个刺猬 /doge

[Guidoo]

好家伙 套娃 表中表中表中表中表中表中表中表中

[aliveyang]

他以为动态了，其实是乱搞

[Leviathann]

元编程是吧

[conanforever22]

他可能是觉得项目中有很多这种“类似”的关系， 不想建那么多表

感觉像我们平时分析某个业务场景， 经过思考，抽象出了一个精炼“通用”的结构；可能真的通用，能应对未来各种变化；也可能忽视了这些变化，然后各种 if...else...特殊处理

看表结构里他还建了很多预留字段，可能是考虑到某些关系可能会附加一些属性，如果能解决问题也没有性能问题，其他同事也能看懂没意见，管他呢...

[guisheng]

个人觉得，这种做法在解决问题上是没有什么好说的。但是在可维护性上和可扩展性上 直接一巴掌拍死。

[guanhui07]

不合理

[pepesii]

这有点像 CASBIN 的 RBAC 模型呢

[twing37]

第一感觉是 casbin 的模型

[konakona]

这个表中表的设计必须是 1:1 的关系就是合理可用且没有诟病的，我指的是：

Aid | Bid | model | remark
1 | 2 | string | ...

比如 Aid 的 field name 可以是 permission_id，Bid 的 field name 可以是 model_id 或者 role_id，model 的 field name 可以是某种 type （比如 model_type 或者任何能够代表操作类的 field name 去说明它）

这个表不能复杂，最多就这么 3-4 个主要子段，因为它的定位应该是一个“中间表”。但……这也只是中间表，如果要在一个表里完成复杂的蛛网一般的交织，后续维护和理解成本（主要体现在陈长的代码里）会比较麻烦，不易维护和改造。

[konakona]

我看了看楼主的 append，这个小伙的做法好像没什么问题啊- - 很常规，很 ok 。建议看下 casbin 。。。

[ericls]

GenericForeignKey

[mejee]

感觉是建立了一个表达通用关系的表，如果是的话，可能也是很合适的

[Casbin]

这是 Casbin

[ericls]

@Casbin 你才是 Casbin