Re: Party Relationship Best Practices

Posted by BJ Freeman on
URL: http://ofbiz.116.s1.nabble.com/Party-Relationship-Best-Practices-tp170029p170031.html

constraints are to make sure that there is data supporting what has been
put in one place in another place, generally speaking.
I have achieved this by using link table in a DB, that have the
relationship constraints.

so only when the link table is in  a view do you have the constraints.

THis would be a lot of two parm entities, but would satisfy almost any
linking system you want.
Then it would be a matter of building Views as the layer that is
constant for backward compatibility.

if that makes sense :\

Chris Howe sent the following on 7/24/2006 11:35 AM:

> 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
>