database-design - 基于角色的访问控制数据库设计

Question

这个问题与 RBAC 系统本身的数据库设计无关，而是当该 Web 应用程序允许其用户提交内容时，如何将该数据库与特定于应用程序的数据库结合使用。

就目前而言，我的 RBAC 应该可以轻松用于简单的后端管理应用程序，员工可以在其中添加和更新记录 - 例如在线商店通常没有用户提交的内容。这两个数据库可以保持独立。但是，我不确定如何在允许用户提交内容的网站/应用程序中重用我的 RBAC 设计。我将在需要添加/更新记录权限的两个数据库中有两个用户表。

我是否将我的 RBAC 数据库合并到网站数据库中并共享用户表？

我是否将两者分开？

做点别的？

如果选项 2 我是否:

(A) 将网站数据库中的用户复制到RBAC用户表

(B) 建立与网站数据库中user表的关系

(C) 在网站数据库中为网站用户创建一个新的 RBAC 系统，并为管理员用户提供单独的 RBAC？

A 看起来很糟糕，因为我正在复制数据，但实现起来似乎很简单。 B 似乎很难与两个单独的用户表建立关系。 C 也是重复，但我可以在不影响“管理员”RBAC 的情况下大量自定义此 RBAC。

我基本上想让我的 RBAC 系统尽可能可重用，并且让特定于应用程序的用户能够提交内容让我有点难以理解。

我的这个小 RBAC 系统主要是我学习的一种方式，所以请不要使用通用的“你应该使用框架 x/y/z”。使用我最近发现的一个术语，我有点像一个轮子 Nerd ，每当我好奇时就喜欢重新发明它们! :)

我将在我的网站上使用 MySQL 和 PHP，但这应该无关紧要，因为这是我在这里询问的数据库设计。

如果我的问题不清楚，请告诉我，我会进一步解释。谢谢大家的时间。

Answer 1

不知道你的完整实现，我倾向于你的第一个解决方案并且只使用一个用户表。然后在线应用程序可以查询 RBAC 以确定用户是否拥有特权。我不清楚需要多少应用程序属性以及它们将存储在哪里。如果您确实有需要存储在数据库中的用户属性，那么您可以在应用程序中创建一个用户表，并使用对 RBAC 的外键引用来确定访问权限，而无需将该数据存储在 2 个位置。这有多复杂取决于您可以添加和更新用户及其属性的不同位置的数量。物理数据库结构非常依赖于您的业务规则和架构，但您的逻辑设计是将数据保存在一张表中。