>Even, may I ask what "argument" convinced you that RI belongs in the biz tier? The fact that your backend might not directly support RI? For me, there's no question that it should belong in the database.

Hi John. Take a look at my first message in this thread to see what convinced me.

RI is not feature of any database, it is a concept of relational design. Specific databases or database tools may enable or allow you to easily enforce RI.

RI - "a database is said to have referential integrity if it has no un-matched foreign key values."

I will paraphrase Roi... My database could be buckets of fish with a spray painted number on the bucket telling which boat the fish came off of. As long as each bucket has a number on it, I have referential integrity. If someone puts some fish into a bucket with no number on it, I have orphan data (fish) and referential integrity is broken.

Also, referential intergrity is not enforced and developed strictly by database admins on a database store. The business domain expert (the user) decides how this is handled. Therefore it appears to be a business rule and depends on how the business is run.

>1. I believe it's a good idea to have the "rules" pertaining to the data reside closest to the actual data it maintains. This would be on the database.

I agree if they pertain to the data itself. But if they pertain to carrying out the business domain no, then they belong in the biz tier.


>3. I believe because 3-tier development is still relatively new concept (within last few years), I don't know too many people that is really good designing the business tier or what should be in it, not counting the fact that most developers I know haven't even done a complete project using it.

I agree. Developers and still grappling with these issues.

>Yes, some of the rules that use to live in the database in a single or 2-tier design (most field-level and record-level rules) will move to the business tier but IMHO, not all and especially not RI (e.g. relationship between tables).

See above.