现在搞开发为什么还要用关系型数据库？

[Hanggi]

最近做一个项目，有一个权限管理模块。 因为数据库用的是 MYSQL，所以本人建议基于 RBAC 做一个功能比较完善的权限管理系统以绝后患。 这个系统最基础结构就是 User-Role-Permission 中间用关系表连接的 5 表结构，不管是权限管理还是特权管理感觉都是很好很流行的方案。 结果公司里人说表太多了，把 permission 表去掉然后把特权用 JSON 数组连接放进 Role 表里这样就能省 2 个表了。

我就不理解了，现在的人是 nosql 用太多了还是怎么了，整天想着把数据放进 JSON 字段里，那还用关系型数据库干什么呢？

哪位大佬帮我分析分析利弊。

[IamNotShady]

如果权限配置不经常变更，这样设计也没问题，但是如果角色的权限经常变动，或者系统增加新的权限，这样搞就有点坑了

[encro]

2 张表也能做 rbac 而且可以多级继承：item(id,type,name)，assignment(id,type,from_id,to_id)，前提是定义好两个 type。

以上实际项目中最好不要用，因为记住多张表会比记住 type 要容易得多，容易记住就等于出错概率少很多。

[reus]

@soulmine 不是表越多就越复杂，字段里存 json，又要对 json 做索引，显然更加复杂

[coang]

......5 个表不是标配吗.. 生成权限 json 这种东西 写个方法缓存一下不就完了???? 删掉关联表存 json??? 本末倒置

[coang]

@xkeyideal 其实在功能表 加上对应的 url 然后在后端 配合 shiro 做认证 不仅仅路由权限可以卡 对应接口权限也可以做校验.. 只是有没有这个闲工夫去做..

[lepig]

为了省 2 张毫无数据量的表，而把数据放到 json 里。我可以明确告诉你，这就是个坑。
维护到后面你就知道了，各种权限更新，判断折磨的要死

[wlkq]

各有优缺点吧，优点：不用联查表，一次就出来了 缺点：角色之间的权限重复的话，需要重复写入，权限无法复用，这里有点坑。如果再频繁更改权限的话，更坑。

[FrankHB]

RDBMS 适合做且其它 DBMS 不适合做的，原则上主要就是连接查询。
（事务支持是实现问题，会影响选型，但不应该是原则问题。RDBMS 本身不蕴含事务支持，NoSQL 也有事务支持较完善的实现。）
所以首先应该有疑问的是：为什么一个系统业务逻辑上不需要依赖连接查询的时候，还要上关系数据库？
——历史包袱罢了。
不过你这里业务上也没必要彻底排除连接（彻底排除想保质保量估计 hold 不住），个别地方多用少用几个算不上是原则问题。
所以就是看人员素质了。要是那些人就是喜欢倒腾 JSON 还保证能应付掉所有需求变动那就随他们去吧，你能把锅甩干净就成……

[dbpe]

这几个字段管生不管养的话，没问题。。

[FrankHB]

@turandothaha 这跟看书有关系？
现在有啥书会告诉你 RBAC model 里的 relation 非得用 RDBMS 实现么。
我寻思 INCITS 359 也没钦定要 RDBMS 啊……
极端点说拿个底层查询引擎再往上糊个什么 duty language 之类的备胎都可行。只是一般场景毫不现实罢了。

[htxf]

各位这样交流真好，不是太懂。。认真学习中。。

[HonoSV]

@coang 支持，我们也是用 shiro 来做接口权限控制的

[dakb]

你的标题起的太挫了吧。

[qiumaoyuan]

省 2 个表的意义是？

[qiumaoyuan]

有时候开发者会为自己设置一些自己都不明白的规则来限制自己。

[turandothaha]

@FrankHB
理论呆子，
你写程序也可以拿二进制往上怼啊，你愿意用 0，1 敲别人还能强迫你？
但是鄙人天资愚钝，还是用高级语言吧。

[www5070504]

节省一两张表好像看着挺机灵 改的时候绝对要司马脸

[z1154505909]

只有写查,没有改的数据存 json 无可厚非,会有改的,弄 json 就是搞事.

[FrankHB]

@turandothaha 才主张“不看书就没有发言权”，一忽儿就评价理论呆子了……似乎还觉得 01 就是理论，也是奇妙深刻 qqqxx
不过我寻思你的确呆子页算不上，因为……比如你连哪本书都没说……打搅了，告辞。

[turandothaha]

@FrankHB
连基本的 KISS 原则都不懂，我还有什么必要跟你交流哪本书？
等你先把话说的清楚明白，少讲废话，大二无用，看似华丽实则空无一物的话，你才算入门。