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
