>Hi all,
>I'm looking at the pro's and con's of the two approaches for handling RI.
>
>xCase gives me the option of generating either or both. I tend to favor constraints just for simplicity but I'm open to other ideas here.
>
>Of course the specific database design will affect the decision on where to use/mix these tools, but I'd like to hear some opinions in general. Thanks.
>
>Gary

Some of the pros of using constraints for RI:
1. Less code ('nuff said)
2. Faster execution.
3. Applications that use the database schema (MS-Access, Visio, Rational Rose, etc...) can use the RI constraints as the foundation of a data model.
4. EM's Database Diagramming tool uses RI constraints to draw nice pictures of your database.
5. Programming tools can use RI constraints to enforce the RI before touching the database, which conserves resources. A good example is .NET DataSets.

The cons:
1. Really old-school database developers will not be able to figure out why they cannot insert a new invoice record for a non-existent customer.
2. Your boss (who is an ex-Clarion developer) will not be able to sabotage your code and criticize you anymore.
3. You may find yourself trading in your '68 junker for a '05 GTO.

There are good uses for triggers in conjunction with constraints. Constraints only deal with one row at a time. The only way to perform entity-level validation is by using a trigger. A good rule of thumb is to always use a constraint when there is a choice.