Re: Party Relationship Best Practices

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

I'm talking about the constraints being managed by a
"constraint entity", where before inputing, updating,
deleting, the entity engine checks the rules for that
associative entity.  

for example if there was a rule that said "only one
tax authority per product" your record would be:
<ConstraintEntity entity="ProductRole"
constraintType="ROLE" constraint="TAX_AUTH"
field="partyId" value="1"/>

--- BJ Freeman <[hidden email]> wrote:

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