http://ofbiz.116.s1.nabble.com/Party-Relationship-Best-Practices-tp170029p170033.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
>>>
>
>