Re: Party Relationship Best Practices

[BJ Freeman]

BJ busy reading, to figure out this Constraint entity.
will check in sometime next week.
:)

Chris Howe sent the following on 7/24/2006 1:20 PM:

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 <[EMAIL PROTECTED]> 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