Just bouncing this idea around. What if the constraints (1 to many, many to many, or in this case each invoiceId can have one party with role type billToParty in the table InvoiceRole) were handled in the application layer instead? Similar to the valid stutus change.
I'm sure there are drawbacks, and I'd love to hear them. (I'll even accept a "that's just silly" response on this one, as it's not based on any theory or read literature. :) ) The benefit of this (at least in my head) is that you wouldn't have to worry about backward compatibility ever again with the data model (which is the biggest problem with backward compatibility), because all relationships would be joins and very standardized. Additionally, describing the data model would be extremely easy as there wouldn't be caveats all over the place, so the learning curve would decrease dramaticaly. Just a thought. =========David Jones wrote: I'm not going to comment on this extensively because of time, but I just wanted you (Chris) to know that I have read over these messages. It looks like the model you are describing is that of a "join" entity that implements a many-to-many relationship between two other entities. The only comment I have on this for Party and PartyRole relating to other entities is that we don't always want a many-to-many relationship. In many cases we want a one-to-many relationship and it would cause problems and lack of clarity in the data model to do otherwise. -David
