实体间抽象引用
我即将进行的一个项目正在考虑一个涉及(我称之为)“抽象实体引用”的设计。这与更常见的数据模型设计有很大的不同，但可能需要实现我们想要的灵活性。我想知道其他架构师是否有类似系统的经验，以及注意事项所在。
该项目需要控制不同人员对各种实体(逻辑上:业务对象；物理:数据库行)的访问。例如，我们可能希望创建如下规则：
- 用户Alice是Z公司的成员
- 用户Bob是Y组的经理，它有用户Charlie、Dave和Eve。
- 用户Frank可以输入关键业务对象X的数据，也可以输入关键业务对象组U中的关键业务对象。
- 用户George不是T公司的成员，但可以查看T公司的报告。
我们的想法是，我们有许多不同的安全对象、角色、组和权限，我们需要一个系统来处理这个问题。理想情况下，这个系统一旦启动，就不需要对新情况进行编码；它应该非常灵活。
在“传统”数据设计中，我们可能有这样的实体/表：
- 用户
- 公司
- 用户/公司交叉参考
- UserGroup
- 用户/用户组交叉引用
- CBO (“关键业务对象”)
- 用户/CBO交叉引用
- CBOGroup
- 用户/CBOGroup交叉参考
- CBO/CBOGroup交叉参考
- ReportAccess，它是用户和公司之间的交叉引用，专门用于访问报表
请注意大量的交叉参考表。这个系统并不是非常灵活，因为每当我们想要添加一种新的访问方式时，我们都需要引入一个新的交叉引用表；而这又意味着额外的编码。
所提议的系统具有所有主要实体(用户、公司、CBO)引用一个名为实体的新表中的值。(在代码中，我们可能会使所有这些实体子类都是实体超类)。然后还有另外两个表，它引用实体*组，它也是一个实体“子类”。* EntityRelation，它是任何类型的两个实体(包括组)之间的关系。这可能还会有某种类型的“关系类型”字段来解释/限定关系。
这个系统，至少乍一看，看起来会满足我们的很多要求。我们可能会在以后引入新的实体，但是我们不需要做额外的表来处理这些实体之间的分组和关系，因为Group和EntityRelation已经可以处理这个问题了。
然而，我担心的是，这在实践中是否会有很好的效果。实体之间的关系将变得非常复杂，人们(用户和开发人员一样)可能很难理解它们。而且，它们是非常递归的；这将使我们依赖SQL的报告编写人员的工作更加困难。
有人有类似系统的经验吗？
Stack Overflow用户
发布于 2009-01-08 19:13:22
您正在对现实世界中的一组业务规则进行建模，这些规则本身很复杂。所以，不管你怎么做，你的模型都会很复杂，这并不奇怪。
我建议您选择更准确地描述关系的数据库设计，而不是试图变得聪明。您的巧妙设计可能会导致更少的表(实际上不是一个数量级的表)，但是您需要更多的应用程序代码来管理它。
例如，您已经知道它会给用户和报表设计人员造成混乱。另一个缺点是确保“关系类型”列只包含关系中涉及的实体的有意义的字符串。说Bob IsMemberOf UserGroup4是有道理的，但是如果CBO CanViewReportsOf Bob是什么意思呢？此外，如何防止相互排斥的条件，如Bob IsMemberOf Company1和Bob IsMemberOf Company2
您必须在插入数据之前和获取数据之后编写应用程序代码来验证数据(因为您的代码永远无法确定代码的另一部分没有引入数据完整性错误)。您还可能需要编写应用程序代码来对整个数据库执行质量控制检查，并在出现异常时清除它们。
与数据库设计相比，在数据库设计中不可能输入无效的关系，因为数据库元数据包含阻止它的约束。这将大大简化应用程序代码。
您还可以识别分级访问权限，比如如果是Bob CanViewReportsOf Company1，那么他是否应该能够查看作为该公司成员的任何UserGroup或CBO的报告？还是需要为Bob可以阅读的每个实体的报告输入单独的行？这些都是策略问题，无论您使用哪种设计，都会存在这些问题。
回应你的意见：
我当然能够理解拜占庭的例外情况和不断变化的需求，这使得设计简单的解决方案变得困难。
我研究了一些系统，试图对现实世界的政策建模，这些政策变得如此复杂，以至于试图将它们编成软件似乎是愚蠢的。最终，雇佣我的客户会更有效地利用他们的钱雇佣一两个全职行政助理，用纸和铅笔追踪他们的项目。我花了几周时间才在软件中实现的新的例外情况，可能需要几分钟才能向机管局描述。
自动化比手工操作更难。实现自动化的唯一方法是，如果需要更快地跟踪信息，或者需要比人类更大的容量来跟踪这些信息。
https://stackoverflow.com/questions/425350
复制相似问题
腾讯云开发者
