Database design 实体间的抽象引用

我的一个即将到来的项目正在考虑一个涉及（我称之为“抽象实体引用”）的设计。这与更常见的数据模型设计有很大的不同，但可能需要实现我们想要的灵活性。我想知道其他架构师是否有类似系统的经验，注意事项在哪里

该项目需要控制不同人员对各种实体（逻辑上：业务对象；物理上：数据库行）的访问。例如，我们可能希望创建如下规则：

• 用户Alice是Z公司的成员
• 用户Bob是组Y的经理，该组有用户Charlie、Dave和Eve
• 用户Frank可以输入[critical business object]X的数据，也可以输入[critical business object group]U中的[critical business objects]
• 用户George不是T公司的成员，但可以查看T公司的报告

我们的想法是，我们有许多不同的安全对象、角色、组和权限，我们需要一个系统来处理这些。理想情况下，该系统一旦启动，就不需要为新情况编写代码；它应该非常灵活

在“传统”数据设计中，我们可能有如下实体/表：

• 使用者
• 公司
• 用户/公司对照
• 用户组
• 用户/用户组交叉引用
• CBO（“关键业务对象”）
• 用户/国会预算办公室交叉参考
• CBOGroup
• 用户/CBO组交叉引用
• CBO/CBO组交叉参考
• ReportAccess，它是用户和公司之间的交叉引用，专门用于访问报告

请注意大量的交叉引用表。这个系统不是非常灵活，因为任何时候我们想要添加一种新的访问方式，我们都需要引入一个新的交叉引用表；这反过来意味着额外的编码

建议的系统让所有主要实体（用户、公司、CBO）在名为Entity的新表中引用一个值。（在代码中，我们可能将所有这些实体都作为实体超类的子类）。然后还有两个引用实体的附加表 *组，它也是一个实体“子类”。 *实体关系，是任何类型的两个实体（包括组）之间的关系。这可能还有一些“关系类型”字段来解释/限定关系

至少乍一看，这个系统似乎可以满足我们的许多要求。我们可能会引入新的实体，但我们永远不需要使用额外的表来处理这些实体之间的分组和关系，因为Group和EntityRelation已经可以处理这些了

然而，我担心这在实践中是否会起不到很好的作用。实体之间的关系将变得非常复杂，人们（用户和开发人员）可能很难理解它们。而且，它们是非常递归的；这将使我们依赖SQL的报表编写人员更加困难

---

有人有过类似系统的经验吗？

我有一个奇怪的经历；详情如下:

架构师/程序员设计外观对称的通用模型，该模型看起来非常整洁，非常像树，并且是递归的

当涉及到用户界面设计时，客户或用户坚持认为实际使用要简单得多，并且会对这两个简单的屏幕感到满意（用户/客户在黑板上为您绘制这些屏幕，您可以一边听）

在这个阶段，我始终发现，当底层模型支持没有人真正想要或需要的非常通用的用例时，解决方案往往会变得非常臃肿。因此，我的基本建议是始终非常密切地倾听客户的意见，并非常密切地关注真正的需求。确保你个人对整洁结构的渴望不是这里的驱动力

是的，我已经经历过很多次了：在我最近的经历中，所有的开发人员都绝对确信我们讨论的是层次结构树结构。但客户明确希望在所有方面都采用类似于平面列表的结构。在我们屈服之前，我们必须做一个完整的循环（先实现树，然后列表）

---

我不完全确定你所建议的通用模型，但它的所有气味让我开始谈论过于通用的模型。在选择之前，我至少会非常肯定地对两个备选方案进行详细建模

您正在为现实世界中的一组业务规则建模，这些规则本身就很复杂。所以，不管你怎么做，你的模型都会很复杂，这并不奇怪

我建议您选择更准确地描述关系的数据库设计，而不是试图变得聪明。您的巧妙设计可能会导致更少的表（虽然实际上不是一个数量级），但您需要权衡的是管理更多的应用程序代码

例如，您已经知道这会给用户和报表设计者带来混乱。另一个缺点是确保“关系类型”列只包含关系中涉及的实体的有意义字符串。例如，说

Bob是UserGroup4

的成员是有道理的，但是如果

CBO可以查看Bob

的报告，这意味着什么呢？另外，如何防止相互排斥的情况，例如

Bob ismemberofcompany1

和

Bob ismemberofcompany2

您必须在插入数据之前和获取数据之后编写应用程序代码来验证数据（因为您的代码永远无法确保代码的另一部分没有引入数据完整性错误）。您可能还需要编写应用程序代码来对整个数据库执行质量控制检查，并在出现异常时清除异常

比较机智