sql - “party model”的原理和好处是什么？

Question

“当事人模型”是用于关系数据库设计的“模式”。至少其中一部分涉及寻找许多实体(例如客户，员工，合作伙伴等)之间的共性，并将其作为更多“抽象”数据库表的要素。

我想了解您对以下方面的看法:

政党模式背后的核心原则和动力是什么？

它对您对数据模型有何规定？ (我的观点是相当高级的，在某些方面可能很不正确。我一直在使用它的项目中，但是我正在与另一个专注于其他问题的团队合作)。

您的经历使您对此有什么感觉？您是否使用过，如果使用过，会再次使用吗？优缺点是什么？

派对模型是否限制了您对ORM的选择？例如，是否必须消除某些ORM，因为它们在域对象和物理数据模型之间没有足够的“抽象层”？

我敢肯定，每个回答都不会解决所有这些问题...但是任何涉及一个或多个问题的内容都将帮助我做出一些我面临的决定。

谢谢。

Answer 1

1. What are the core principles and motivating forces behind the party model?

就我所使用的程度而言，它主要是关于代码重用和灵活性的。我们之前在guest / user / admin模型中使用过它，当您需要将用户从一个组转移到另一个组时，它肯定会证明其值(value)。将其扩展为让组织和公司在其下具有用户代表，这实际上提供了一种SQL并不是特别固有的抽象形式。

2. What does it prescribe you do to your data model? (My bit above is pretty high level and quite possibly incorrect in some ways. I've been on a project that used it, but I was working with a separate team focused on other issues).

尽管上面需要更多细节，但是您在上面的部分中是非常正确的。您可以想象这样一种情况，即数据库中的实体(称为一方)外包给另一方，这又可能将工作分包出去。政党可以是雇员，承包商或公司，是政党的所有子类。根据我的理解，您将拥有一个Party表，然后是每个子类的更具体的表，然后可以将其进一步子类化(Party-> Person-> Contractor)。

3. What has your experience led you to feel about it? Did you use it, and if so, would you do so again? What were the pros and cons?

如果您需要灵活地将新类型添加到系统中，并在开始时没有想到的类型和架构师之间建立关系(用户升至新级别，公司雇用其他公司，等等)，则它有其好处。它还使您可以运行单个查询并检索多种类型的参与方(公司，员工，承包商)的数据。另一方面，您要添加其他抽象层来获取实际需要的数据，并在查询特定类型时增加数据库的负载(或至少是连接数)。如果抽象程度过高，您可能需要运行多个查询来检索数据，因为复杂性将开始对可读性和数据库负载产生不利影响。

4. Did the party model limit your choice of ORMs? For example, did you have to eliminate certain ORMs because they didn't allow for enough of an "abstraction layer" between your domain objects and your physical data model?

我承认这是一个薄弱的 Realm ，但是我发现在应用程序层中使用 View 和镜像抽象并不会造成太大的问题。对于我来说，真正的问题一直是我想直接读取数据源时“数据X存放在哪里”(对于系统上的新开发人员也不总是直观的)。