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

问题描述

派对模式是关系数据库设计的模式。其中至少有一部分涉及到许多实体（如客户，员工，合作伙伴等）之间找到共同点，并将其视为更多的抽象数据库表。

我想了解以下内容的想法：

1. 派对模式背后的核心原则和激励力是什么？


2. 你对数据模型做了什么规定？ （我上面的位置是相当高的水平，在某些方面可能是不正确的，我一直在使用它的项目，但是我正在与另一个专注于其他问题的团队合作）。

<你有什么经验让你感觉到？你是否使用它，如果是这样，你会再次这样做吗？什么是利弊？

3. 派对模式是否限制了您对ORM的选择？例如，您是否必须消除某些ORM，因为它们不允许您的域对象和物理数据模型之间的抽象层足够？

我确信每一个回应都不会解决每一个问题，但任何关于一个或多个问题的任何事情都会帮助我做出我所面临的一些决定。

谢谢。

解决方案

在我使用它的程度上，它主要是关于代码重用和灵活性。我们以前在客户/用户/管理模式中使用它，当您需要将用户从一个组移动到另一个组时，它肯定证明了它的价值。扩展这一点，让组织和公司代表用户在他们之下，它真的提供了一种在SQL中不是特别固有的抽象形式。

< ol start =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屋！