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

[Hanggi]

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

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

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

[Yourshell]

三个表就嫌多吗

[Defned]

casbin 了解一下，一张表搞定，当然也可以不用表

[lonelygo]

用户权限，这么有“关系”的事情用“关系库”挺好啊。
表不怕多，怕不可理

[A555]

整天搞这种骚操作给后面的人埋坑

[cccy0]

看业务把, 毕竟关系型还是有优势的

[zhixuanziben]

感觉这是在挖坑啊，那么经典的 rbac 模型，5 张表。为了省表，到时候拓展起来就要哭了。

[awesomes]

实际上，可以用一个 JSON 把所有表的数据都搞定，你说呢

[swulling]

你的做法是对的，这种需求用 sql 最合适了

[hsluoyz]

+1，直接用 Casbin 吧，简单、灵活，把精力省下来用在其他地方，没必要重复造轮子

[DaWWW]

这个单看楼主的描述，其实怎么实现都没问题，但应用场景和规模会决定用什么更好，不能一概而论，并没有单纯的好或者不好。我觉得楼主如果有针对实际需求的完整的方案，还是可以据理力争的。有件事情，真的真的非常重要，软件项目的成功，依靠的是社交，而非技术。

[leegoo]

RBAC 的话 数据量应该不会很大吧,毕竟是针对后台管理的
关系型数据库挺好的啊,为啥一定要上 NoSql
而且 RBAC 更多的是与业务权限进行关联,肯定多表查询的几率会很大, 而 NoSQL 对于多表查询并不友好吧(虽然可以使用多次单表操作)
况且,省了几个表 后期维护的成本变高了很多,表和表之间的关系也耦合在一起了,后期想要扩展想必肯定是一件很头疼的事情吧
再说了

[soulmine]

你的观点是以绝后患 那么存在这个后患么？后患的几率多少 有必要用 5 个表么？ 2 个表行不行 能不能完成？ 不是所有东西都是越复杂越好的 得看实际需求

[kyuuseiryuu]

因为所谓的业务系统就是把现实中的对象的属性、行为以及对象与对象之间的关系用计算机语言描述出来。

所以注重“关系”的业务一般都采用关系型数据库。

[xuanbg]

@xkeyideal 数据权限不好实现的根本原因是数据资源难以定义。在你的权限体系里面，signKey 其实就是数据资源。但我没看明白你这个 signKey 是如何产生的，这个关键点能详细说一下吗？

[xuanbg]

@Lucups 主流框架集成的不是用户身份认证吗？就算是身份认证，也是只有最简单的功能。我还不知道哪个主流框架集成了权限管理，也想不明白权限管理这种严重依赖数据库的功能要怎么集成在框架里面。

[cabing]

如果没啥量，需要考虑可维护性。

数据库字段里面存 json，除非是一次性存取的，不然很危险，维护起来超级麻烦，如果后续有变更啥的或者是开发随意定字段啥的，你们维护起来会哭的。真的，别问我为什么知道。。

[springmarker]

很多业务其实单表就够了，像 mongo 这种连表查询能烦死个人，但是照样很多人用

[turandothaha]

不看书就没有发言权，不知道从哪里看到现在可以不用关系型数据库的？
没看见有可替代的东西，也没看见要式微的迹象啊，nosql 能替代关系型数据库？
还是先找本书看看吧。

[Salvation]

。。。。。。。。。

感觉都没有人说到非常重要的一点，表结构这些玩意的最优方案，都是从领域模型+业务场景推导出来的。不是一上来就看 db 应该怎么设计。

单单要说怎么存储，那怎么存储都可以，用不着纠结，关键是能不能说清楚核心原因。

[nl101531]

没理解多两张表的复杂性在哪，多的两张也只是权限配置表，那么在组装用户 domain 的时候，对上层是屏蔽了这些东西，没有带来太多复杂性吧。