[ACCEPTED]-What are the principles behind, and benefits of, the "party model"?-data-modeling

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

To the extent that I've used it, it's mostly 46 about code reuse and flexibility. We've 45 used it before in the guest / user / admin 44 model and it certainly proves its value 43 when you need to move a user from one group 42 to another. Extend this to having organizations 41 and companies represented with users under 40 them, and it's really providing a form of 39 abstraction that isn't particularly inherent 38 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 37 above, though it needs some more detail. You 36 can imagine a situation where an entity 35 in the database (call it a Party) contracts 34 out to another Party, which may in turn 33 subcontract work out. A party might be 32 an Employee, a Contractor, or a Company, all 31 subclasses of Party. From my understanding, you 30 would have a Party table and then more specific 29 tables for each subclass, which could then 28 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 27 has its benefits if you need flexibly to 26 add new types to your system and create 25 relationships between types that you didn't 24 expect at the beginning and architect in 23 (users moving to a new level, companies 22 hiring other companies, etc). It also gives 21 you the benefit of running a single query 20 and retrieving data for multiple types of 19 parties (Companies,Employees,Contractors). On 18 the flip side, you're adding additional 17 layers of abstraction to get to the data 16 you actually need and are increasing load 15 (or at least the number of joins) on the 14 database when you're querying for a specific 13 type. If your abstraction goes too far, you'll 12 likely need to run multiple queries to retrieve 11 the data as the complexity would start to 10 become detrimental to readability and database 9 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 8 a bit weak in, but I've found that using 7 views and mirrored abstraction in the application 6 layer haven't made this too much of a problem. The 5 real problem for me has always been a "where 4 is piece of data X living" when I want to 3 read the data source directly (it's not 2 always intuitive for new developers on the 1 system either).

The idea behind the party models (aka entity 22 schema) is to define a database that leverages 21 some of the scalability benefits of schema-free 20 databases. The party model does that by 19 defining its entities as party type records, as 18 opposed to one table per entity. The result 17 is an extremely normalized database with 16 very few tables and very little knowledge 15 about the semantic meaning of the data it 14 stores. All that knowledge is pushed to 13 the data access in code. Database upgrades 12 using the party model are minimal to none, since 11 the schema never changes. It’s essentially 10 a glorified key-value pair data model structure 9 with some fancy names and a couple of extra 8 attributes.

Pros:

• Kick-ass horizontal scalability. Once your 5-6 tables are defined in your entity model, you can go to the beach and sip margaritas. You can virtually scale this database out as much as you want with minimum efforts.
• The database supports any data structure you throw at it. You can also change data structures and party/entities definitions on the fly without affecting your application. This is very very powerful.
• You can model any arbitrary data entity by adding records, not changing the schema. Meaning you can say goodbye to schema migration scripts.
• This is programmers’ paradise, since the code they write will define the actual entities they use in code, and there are no mappings from Objects to Tables or anything like that. You can think of the Party table as the base object of your framework of choice (System.Object for .NET)

Cons:

• Party/Entity models never play well with ORMs, so forget about using EF or NHibernate to get semantically meaningful entities out of your entity database.
• Lots of joins. Performance tuning challenges. This ‘con’ is relative to the practices you use to define your entities, but is safe to say that you’ll be doing a lot more of those mind-bending queries that will bring you nightmares at night.
• Harder to consume. Developers and DB pros unfamiliar with your business will have a harder time to get used to the entities exposed by these models. Since everything is abstract, there no diagram or visualization you can build on top of your database to explain what is stored to someone else.
• Heavy data access models or business rules engines will be needed. Basically you have to do the work of understanding what the heck you want out of your database at some point, and your database model is not going to help you this time around.

If you are considering 7 a party or entity schema in a relational 6 database, you should probably take a look 5 at other solutions like a NoSql data store, BigTable 4 or KV Stores. There are some great products 3 out there with massive deployments and traction 2 such as MongoDB, DynamoDB, and Cassandra 1 that pioneered this movement.

This is a vast topic, I would recommend 15 reading The Data Model Resource Book Volume 3 - Universal Patterns for Data Modeling by Len Silverston and Paul Agnew.

I've 14 just received my copy and it's pretty good 13 - It provides you with an overlook for many 12 approaches to data modeling, including hybrid 11 contextual role patterns and so on. It has 10 detailed PROs and CONs for every approach.

There 9 is a pletheora of ways to model party relationships 8 and roles all with their benefits and disadvantages. The 7 question that was accepted as an answer 6 covers just one instance of a 'party model'.

For 5 instance, in many approaches, notions like 4 "Employee", "Project Manager" etc. are 3 roles that a party can play within a certain 2 context. I will try to give you a better 1 breakdown once I get home.

When I was part of a team implementing these 17 ideas in the early 1980's, it did not limit 16 our choice of ORM's because those hadn't 15 been invented yet.

I'd fall back on those 14 ideas any time, as that particular project 13 was one of the most convincing proofs-of-concept 12 I have ever seen of a "revolutionary" idea 11 (which it certainly was at the time).

It 10 forces you to nothing. And it doesn't stop 9 you from anything (from any mistake, I mean). The 8 one defining your own information model 7 is you.

All parties have lots of properties 6 in common. The fact that they have a name 5 and such (we called those "signaletics"). The 4 fact that they have principal/primary locations 3 called "addresses". The fact that they 2 all are involved, in some sense, in the 1 business' contracts.

as a simple talk from my understanding: Party 8 modeling gives the flexibility and needs 7 more effort (like T-sql join and ...) to 6 be implemented.
I also wanna point that, "using 5 Party modeling (serialization/generalization) gives 4 you the ability to have FK-Relation to other tables". for 3 example: think of different types of users 2 (admin, user, ...) which generalized into 1 User table, and you can have UserID in your Authorization table.