问实体间抽象引用

EN

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

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

例如，您已经知道它会给用户和报表设计人员造成混乱。另一个缺点是确保“关系类型”列只包含关系中涉及的实体的有意义的字符串。说Bob IsMemberOf UserGroup4是有道理的，但是如果CBO CanViewReportsOf Bob是什么意思呢？此外，如何防止相互排斥的条件，如Bob IsMemberOf Company1和Bob IsMemberOf Company2

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

与数据库设计相比，在数据库设计中不可能输入无效的关系，因为数据库元数据包含阻止它的约束。这将大大简化应用程序代码。

您还可以识别分级访问权限，比如如果是Bob CanViewReportsOf Company1，那么他是否应该能够查看作为该公司成员的任何UserGroup或CBO的报告？还是需要为Bob可以阅读的每个实体的报告输入单独的行？这些都是策略问题，无论您使用哪种设计，都会存在这些问题。

回应你的意见：

我当然能够理解拜占庭的例外情况和不断变化的需求，这使得设计简单的解决方案变得困难。

我研究了一些系统，试图对现实世界的政策建模，这些政策变得如此复杂，以至于试图将它们编成软件似乎是愚蠢的。最终，雇佣我的客户会更有效地利用他们的钱雇佣一两个全职行政助理，用纸和铅笔追踪他们的项目。我花了几周时间才在软件中实现的新的例外情况，可能需要几分钟才能向机管局描述。

自动化比手工操作更难。实现自动化的唯一方法是，如果需要更快地跟踪信息，或者需要比人类更大的容量来跟踪这些信息。

我对此有一种奇怪的体验，具体如下：

架构师/程序员设计的是非常对称的通用模型，看起来真的很整洁，而且非常树化和递归。

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

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

是的，我经历了很多次:在我最近的经历中，所有的开发人员都绝对确信我们在谈论的是一种分层树结构。但在所有方面，客户都坚决希望这是一个扁平的列表式结构。在我们屈服之前，我们必须进行一个完整的循环(先实现树，然后再列出)。

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

你的实体/关系提案是如此“元”，以至于它足够灵活地处理所有疯狂的排列--你离一个只有一列的表只有一步之遥，其中包含实现它的逻辑的类的路径--但是正如你所指出的，直接管理它会导致疯狂的混乱。您需要从业务对象层(re:单表继承？)将一个漂亮的包装器放在上面。隐藏所有的抽象。但在你经历这些麻烦之前，看看其他已经建立起来的系统。大多数时候，我发现自己掉进了这个兔子洞里，我最终实现了Unix文件系统权限，这一点不足为奇地经受住了时间的考验。