假设有一个系统，您有三个实体：
您想建立一些权限关系，无论如何都要具有数据库的灵活性，例如：
- 用户X可以更改用户Y的权限
- 用户X可以更改小组Y的权限
- 用户X可以更改角色Y的权限
- 团队X可以更改角色Y的权限
- X队可以更改Y队的权限
- 角色X可以更改团队Y的权限
- 角色X可以更改角色Y的权限
在类似的情况下，我目前有一个具有以下架构的表：
- SubjectType（用户|团队|角色）
- SubjectId （整数-不是外键）
- TargetType（用户|团队|角色）
- TargetId （整数-不是外键）
这允许在一个地方指定所有关系，但是，由于没有指定的关系，因此存在问题：
- 角色A配置为有权访问团队ID为X，Y，Z的团队
- 删除了Y和Z团队，其他地方都没有错误
- 查询角色A的目标时，仍返回团队ID Y和Z。
就目前而言，我可以看到两个选项，每个选项都涉及折衷方案（赞成= +，反对=-）：
1。将数据保留在一个位置，但是在删除实体时删除孤立的权限关系。
- （+）保持一个表和单个查询的简单性
并在删除团队后手动删除团队权限条目
- （-）将需要3个手动删除操作（用户|团队|角色）。虽然只有一个删除功能可以重复进行，但没有固定和快速的保证书
2。在自己的表中指定每个关系。
- （+）ACID保证将防止条目变为孤立
- （-）更大的表格详细程度，7-9个表格用于基本相同的事情
- （-）更多查询，更多联接（特别是在使用类表继承的情况下）
我倾向于第二种选择，是在下面添加额外的复杂性并将其抽象为单个访问函数，并认为这值得进行额外的工作（涉及一些重写）。
但是，我想知道我是否错过了其他选择，或者是否有一些针对此问题的经验丰富的建议？
使用带有此设置的SQL Server 2012，但我认为这是一个常见的SQL /数据库问题。