title: What are the principles behind, and benefits of, the "party model"?
body: <p>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. </p>
  
  <p>I'd like to find out your thoughts on the following: </p>
  
  <ol>
  <li>What are the core principles and motivating forces behind the party model?</li>
  <li>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).</li>
  <li>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?</li>
  <li>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?</li>
  </ol>
  
  <p>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.</p>
  
  <p>Thanks.</p>