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