Ahh... Let me try to rephrase this to see if I understand.
RI rules can not be business rules because that means the biz rules are making an assumption that the data is relational. An assumption that it should not be making.
>I just read most of the messages in this thread and have to disagree with most of them. But rather than answering individually, I'm starting a new branch here...
>
>First of all, I want to stress the fact that this is a very important question that has to be answered very early in the design cycle in order to guarantee flexibility and a clean architecture.
>
>Also, I want to point out that what we call referential integrity in Visual FoxPro has historically grown into what it is today, but doesn't really fit the n-tier model. VFP mixes all kinds of data and treats it the same way, no matter whether business logic or technical issues are the cause for certain design. I think this is why so many different opinions come up here...
>
>Let's have a look at a couple of different examples:
>
>- Let's say we have a customer table and a phone numbers table. There is a 1:n relation between those tables, so the customer can have an unlimited number of phone numbers.
>Now let's say we want to delete the customer. Of course, we also have to delete all the phone numbers for this customer. So where do we put the logic for that? I say it's the data tier. Here's why:
>The fact that a customer has many phone numbers is a natural. If we weren't to think about customer data in terms of tables (which is a very FoxPro (relational data) specific thing to do) but "entities", the customer table and the phone numbers table would be one entity and the fact that it's stored in two different tables is a VFP specific implementation issue. If we were to move to another non-relational back end (such as XML or maybe an object database), we wouldn't have a 1:n relation here. The customer would simple have sub-nodes or a phone number collection instead of a second table. Therefore, if the business logic tier was trying to delete phone numbers, it would fail miserably, rendering our app inflexible and useless in that scenario.
>
