tl;dr:我如何实现像(例如)github 的 这样的权限模型
更新以尝试解决@philipxy 的一些评论:
我计划实现类似于 github 的权限模型:
这些权限将控制谁可以对站点中的 Assets 、组和组织执行创建、读取、更新和删除 (CRUD) 操作。
我大约如何建模？
显然我有这些模型:
接下来是什么？
我正在使用 node 中的 mysql(通过 sequelize)，但我可以自己找出特定的语法，我只是还没有想出如何在概念上做到这一点。
更多@philipxy 的观点:
你建议我做的更多的事情确实是我认为我正在寻求帮助的事情。也就是说，那些信息设计方法(NIAM、FCO-IM、ORM2、IDEF1X)正是我正在寻找的。我对关系数据库的实现有相当多的了解(学习规范化和规范形式等的天数)，但实际上，指定业务需求并将其转换为可操作规范的过程是一个挑战。
我想我要拿起一本数据库教科书。
更多关于谓词的工作:
U 标识一个 User A 标识一个 Asset G 标识一个 Group User U 可以在 0 个或多个 Groups 0x251812231343214131343214319G 标识一个 O Organization User 可以在 0 个或多个 U 0x251812231343214131343214319Organizations O 可以在 0 个或多个 Group 0x251812231343214131343214319G 可以由 Organizations O A 上:User U能够允许(通过Assets Entity？)对E Permission P 是:Ac Assets Actions Create Read 可能是以下类型:Update Delete Entity User/“公众” Group 显示，但也与 Organization 、 Anonymous User 和 0x231318 相关)3:3Read Create可以允许另一Update Delete到User一个U0 User U1 Read可以允许Asset A谁是User U0到Users的U Group G Read可以允许Asset A谁是User U0到Users的U Organization O Read在Asset A，其中Users是U即处于Group G1已经允许G1 Group Organization，因此允许O Read Asset A Read 引用 Asset A 只能由某些用户创建:Permission P 的创建者 Asset 可以创建 0x2518122413 的 0x2518122413 2313131231312313123131313131313131231314131314132313313131313131313131313131313131313141A 到他们有 User(在基本情况下:那些 U 由 0x23131313132313131341313131313131341 创建)Entity Permissions ed 权限也可以引用 Entity 0x2518122313131341 0x2518122313213131313131313131341313413134131313413134131341313131313131313131313131341之间Assets 标识一个 PermissionAssets 赋予 U 创建、读取、更新或删除 User 的权限，该权限引用另一个 0x231313131313134131341Grant(?) ， Entity 具有传递性，因为:E Permission一直Gr的特权(例如)修改为Grant Grant Entity，然后Permissions 的成员 Entity 修改 Permissions 引用 0x251812231341,1334Grants谁是任何Organization O其中Granted是Permissions的成员有权限修改Entity引用E 最佳答案
谓词和表
命题是对业务情况的真假陈述。谓词是一个列参数化的语句，给定一行给出一个命题。一个表(基本或查询结果)保存从其谓词做出真命题的行。
user (with id) U has name N
R is a grantor (may grant permissions)
user U has permission to update asset A
grantor R gave permission to grantor E to use an operator of type 'CRUD'
grantor E is of type 'user' AND grantor E has permission to update assets
业务规则
业务规则是定义术语或描述策略或流程的始终为真的语句。
A user is uniquely identified by an id assigned when their cheque clears.
A crudable is an asset, group or organization.
A grantor is a user, group, organization.
"Grantee" refers to a grantor receiving or holding a permission.
Users can be in organizations.
您可以做出无参数谓词的真语句。这些可以使用由
FOR ALL & FOR SOME ( THERE EXISTS ) 绑定(bind)的参数名称。用这种命题谓词和/或表名表述的业务规则是数据库约束。给定 User(U,N) & Grantor(R) 作为上面前两个谓词的简写，作为表 User & Grantor 的谓词，以下几行都说同样的话:A user is a grantor.
FOR ALL U, if U is a user then U is a grantor.
FOR ALL U, (FOR SOME N, User(U, N)) IMPLIES Grantor(U).
(SELECT U FROM User) ⊆ (SELECT R AS U FROM Grantor).
FOR ALL U & N, User(U, N) IMPLIES Grantor(U).
FOR ALL U & N, (U, N) IN User IMPLIES (U) IN Grantor.
FOREIGN KEY User (U) REFERENCES Grantor (R); 说明了上面的内容(注意它与中间两个的相似之处)加上在 Grantor 中 R 是 UNIQUE NOT NULL。不要将规则与谓词混淆。它们有不同的用途和通常不同的形式。 (无参数句子模板可以用作两者之一。)规则是真实的陈述；谓词是参数化语句。看看我的答案如何将它们分开。基表和查询结果表都有谓词。但是规则可能表明您需要一个基本谓词/表来记录某些内容。当我们从规则中看到我们必须记录一些关于当前情况的陈述时，我们就有了基本谓词/表。请注意，某些规则不会激发任何基本谓词。
您可能想要具体化类型和权限。
A user is a grantor of type 'user'.
Permission named 'C' is permission for a grantee to create a crudable.
Grantor E is of type 'user'.
Permission P is of type 'CRUD'.
Grantor R gave permission P of type 'CRUD' on crudable C to grantee E.
设计正在寻找必要和充分的规则和基本谓词
以下是相关谓词，用于记录您的说明建议出现的情况。
U identifies a user
G identifies a group
user U is in group G
O identifies an organization
user U is in organization O
group G is in organization O
A identifies a crudable of type 'asset'
user U is permitted CRUD operations on crudable C
P identifies a permission
organization O is permitted CRUD operations on crudable C
crudable C is public
grantor R has permission to set CRUD permission for users on crudable C --?
什么是“上述权限”？也许您的意思是用户 CRUD 权限和组织 CRUD 权限？也许您的意思是操作创建、读取等有单独的权限？你需要更清楚。
“一组权限”中的权限是什么？此处的“许可”是指“对特定受让人的特别许可”吗？你需要更清楚。
更清晰的方法是提供尽可能简单的规则和谓词，但也不能简单到不提及相关实体/值。之后您可能希望将多个规则和谓词概括为单个规则。例如，不是与用户、组、组织和 Assets 打交道，而是拥有授予者和 crudable:
Grantors may grant permissions. & grantor R gives permission P to grantee E 。如果某些此类权限也与特定的受让人相关联，您可能还需要诸如 grantor R gives permission P to grantee E re permission Q and grantee F 之类的谓词。user U created crudable C
user U has permission to set permission P for crudable C --?
你会想要记录像
user U has name N and ... 这样的东西。了解数据库设计
搜索数据库/SQL 子类型/继承/多态性习语。例如，用户、组和组织是权限拥有者和持有者的类型；我使它们成为类型授予者的子类型。也许您想要某种权限目标类型，即 crudable 和授予者的联合。也许您需要权限类型。也许某些权限具有关联的被授予者。也许“C”、“R”、“U”和“D”是权限，而“CRUD”是一种权限。您可能想要记录授予者授予受赠者何种权限。
稍后，如果连接在共享 PK/UNIQUE 上，并且两者中具有相同的值集，我们可以通过它们的连接替换表。当我们可以在 PK/UNIQUE & FK 上加入时，我们可以像他们的加入一样将表替换为一个，但 FK 可以为空。还有其他时候，我们可以毫无问题地用一张表替换多张表。但首先要确定基本谓词。
了解关系数据库设计。遵循一些信息设计方法。最好的是 NIAM/FCO-IM/ORM2 系列的成员。看看 IDEF1X。不要依赖产品。
了解约束。它们遵循谓词和业务规则。根据谓词，它们是关于可能的业务情况的真理。等效地，它们是关于表中可能的数据库状态的真理。还了解 SQL 中的约束，包括声明式(PK、UNIQUE、FK)和触发式。
关于database - 我如何建立关系模型(类似 GitHub 的)权限？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/42283793/