Re: Party Relationship Best Practices

Posted by cjhowe on
URL: http://ofbiz.116.s1.nabble.com/Party-Relationship-Best-Practices-tp170029p170030.html

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