Well, let me put my 2-cents in here....

In a broader sense, we are talking about data integrity. What does that comprise?

Entity Integrity - Ensuring that each row can be uniquely identified (PK's). Primary Key constraints handle this one.
Domain Integrity - Ensures proper values are entered into columns. This is the whole business rule stuff. SQL Server would like this stuff to be added as check constraints. We can do the same thing in VFP. The pro side to this that you biz rules and database are bound. The bad news is that resuse with respect to your biz rules is not achieved. Also, depending on load, scaleability issues may result as well. My opinion is that this stuff belongs in COM Components.
Referential Integrity - You know this one, no children without a parent, cant delete in some cases..yada yada yada... In VFP, this is handled by triggers. In SQL however, you have some choices. There is always a foreign key constraint setup in SQL. Whether it is activated for updates, deletes, inserts (the triggers) - is up to you.

Personally, I am not a fan of triggers. Rather, I like the idea of FK constraints, and using that meta data to build stored proc code. This puts everything under my control. It prevents me from having to cede 100% control to the DB engine. This stuff IMHO, belongs in stored procs.

So....

PK Enforcement - The DB Engine
Business Rules - COM Components
RI - The DB Engine via FK Constraints and Stored Procs - not triggers...





>Yeah, it was interesting. I agree that the database design is driven by the business rules, but I don't think there was ever a conculusion reached on where to implement things like RI, in COM objects or in the database. Both sides had valid arguements. I lean to letting the database handle it..but the biz rules definately define how the RI is done.
<