>Relations between entities need to be enforced by the business logic. Relationships within one entity are technical issues (that typically only occur in relational systems). Therefore, they need to be handled in the data tier, so we can swap the data tier our easily.
>
>Markus

I think this is where the difference between object modeling, data modeling, and mapping the two comes into play. I think most VFP programmers thik of things in terms of DATA... Since we are so close to data we see that a Customer with Phone numbers and Addresses are in different tables and where used to dealing with this in 2.6.

But, now we are modeling a Business Object, which says nothing about the data... and we have a DBA model that data... Then we map the two togther... So, when the DBA models the data for the Customer Object we don't care how he mapped it table wise...

Thinking from the Object point of view, if I delete a Customer, how the underlying persistent data is removed is an implementation issue based on the database that is being used.

Ok... so, if all of the above is really true, I am confused as to the Customer / Invoice issue... If I delete a Customer I may or maynot want to remove the invoices? So, that is a business rule?

Ok. Say I DO want to remove all invoices for a customer delete... now I have to IMPLEMENT that business rule... would I implement the rule in the Middle Tier Customer Object or Invoice object... or would I add a Stored Procedure to my Data Tier which removes invoices for a passed customer id... and call it from the Customer Deleter Trigger.

Is that RI? Does it matter? Does it matter where I implement that business rule? I would think that if I 'strickly' wanted to maintain Business Rules seperate from Data then I would implement this casecade delete in the Business Layer...

Are we saying NEVER implement business rules in the Data Tier?

BOb

BTW: Great thread... Marcus, you really clarified alot of this for us.