“政党模式"背后的原则和好处是什么? [英] What are the principles behind, and benefits of, the "party model"?

问题描述

派对模式"是关系数据库设计的一种模式".它至少有一部分涉及找到许多实体(例如客户、员工、合作伙伴等)之间的共性，并将其分解为一些更抽象"的数据库表.

我想了解您对以下问题的看法:

1. 政党模式背后的核心原则和动力是什么?
2. 它对你的数据模型做了什么规定?(我上面的内容非常高级，在某些方面很可能不正确.我一直在使用它的项目，但我正在与一个单独的团队合作，专注于其他问题).
3. 你的经历让你有什么感受?您是否使用过它，如果使用过，您会再次使用它吗?利弊是什么?
4. 派对模式是否限制了您对 ORM 的选择?例如，您是否必须消除某些 ORM，因为它们在域对象和物理数据模型之间没有足够的抽象层"?

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

谢谢.

解决方案

1. 党的核心原则和动力是什么模型?

就我使用它而言，主要是关于代码重用和灵活性.我们之前在访客/用户/管理员模型中使用过它，当您需要将用户从一个组移动到另一个组时，它肯定证明了它的价值.将其扩展为让组织和公司代表其下的用户，它确实提供了一种抽象形式，这种形式在 SQL 中并不是特别固有的.

<块引用>

2. 它对你的数据模型做了什么规定?(我上面的一点是相当高的水平，很可能在某些方面不正确.我一直在使用它的项目，但我是与一个单独的团队合作，专注于其他问题).

你上面的一点是非常正确的，尽管它需要更多的细节.您可以想象一种情况，数据库中的一个实体(称为一方)将合同外包给另一方，而另一方又可能会转包.一方可能是雇员、承包商或公司，所有子类都属于一方.根据我的理解，您将有一个 Party 表，然后是每个子类的更具体的表，然后可以进一步子类化(Party -> Person -> Contractor).

<块引用>

3. 你的经历让你有什么感受?你用过吗，如果所以，你会再这样做吗?什么是利弊?

如果您需要灵活地向系统添加新类型，并在您开始时没想到的类型和架构之间建立关系(用户移动到一个新的水平，公司雇用其他公司等)，它有它的好处.它还为您提供了运行单个查询并为多种类型的各方(公司、员工、承包商)检索数据的好处.另一方面，您正在添加额外的抽象层以获取您实际需要的数据，并且在查询特定类型时增加了数据库的负载(或至少是连接数).如果您的抽象过于深入，您可能需要运行多个查询来检索数据，因为复杂性将开始不利于可读性和数据库负载.

<块引用>

4. 派对模式是否限制了您对 ORM 的选择?例如，你有没有必须消除某些 ORM，因为他们没有足够的之间的抽象层"域对象和您的物理数据模型?

这是一个我承认有点薄弱的领域，但我发现在应用程序层使用视图和镜像抽象并没有使这成为太大的问题.当我想直接读取数据源时，对我来说真正的问题一直是数据 X 活在哪里"(这对于系统上的新开发人员来说也并不总是直观).

The "party model" is a "pattern" for relational database design. At least part of it involves finding commonality between many entities, such as Customer, Employee, Partner, etc., and factoring that into some more "abstract" database tables.

I'd like to find out your thoughts on the following:

1. What are the core principles and motivating forces behind the party model?
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).
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?

I'm sure every response won't address every one of those questions ... but anything touching on one or more of them is going to help me make some decisions I'm facing.

Thanks.

解决方案

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

To the extent that I've used it, it's mostly about code reuse and flexibility. We've used it before in the guest / user / admin model and it certainly proves its value when you need to move a user from one group to another. Extend this to having organizations and companies represented with users under them, and it's really providing a form of abstraction that isn't particularly inherent in 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).

You're pretty correct in your bit above, though it needs some more detail. You can imagine a situation where an entity in the database (call it a Party) contracts out to another Party, which may in turn subcontract work out. A party might be an Employee, a Contractor, or a Company, all subclasses of Party. From my understanding, you would have a Party table and then more specific tables for each subclass, which could then be further subclassed (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?

It has its benefits if you need flexibly to add new types to your system and create relationships between types that you didn't expect at the beginning and architect in (users moving to a new level, companies hiring other companies, etc). It also gives you the benefit of running a single query and retrieving data for multiple types of parties (Companies,Employees,Contractors). On the flip side, you're adding additional layers of abstraction to get to the data you actually need and are increasing load (or at least the number of joins) on the database when you're querying for a specific type. If your abstraction goes too far, you'll likely need to run multiple queries to retrieve the data as the complexity would start to become detrimental to readability and database load.

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?

This is an area that I'm admittedly a bit weak in, but I've found that using views and mirrored abstraction in the application layer haven't made this too much of a problem. The real problem for me has always been a "where is piece of data X living" when I want to read the data source directly (it's not always intuitive for new developers on the system either).

这篇关于“政党模式"背后的原则和好处是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！