I think your second paragraph fairly summarizes the case for DB contstraints.

Attempting to ensure "External" code is written to protect the DB is
a pretty tall order, even within a single company/group of developers.
Once you open yourself to what "shops may chose" - well, that's game over,
I think.

I can think of one reason to avoid putting RI in the DB: when you do not have
a clear object definition. Very common in the "quick and dirty" world I
work in.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: Thursday, October 18, 2012 2:06 PM
To: midrange list
Subject: Pros and Cons of DB defined Referential Integrity Constraints

Up until now I've been content with coding RI constraints in DB I/O modules. For example:

However, this week we've been cleaning up a mess in our database that was caused by our failing to implement an RI constraint in one of our programs. One might ask, where were our QA procedures? While that's a valid concern, the problem could have also been prevented if we added a step to our development process to define RI constraints using DDL or ADDPFCST whenever we add new tables to our database? We're adding new tables every month!

I suppose that one pro for using DB defined constraints is that you use a fairly simple declarative syntax as opposed to program logic. While we generally limit DB inserts and updates to a single RPG I/O module per table, I suppose that another pro for DB defined constraints is that they apply to any other interface that shops may chose to update the DB.

What about other pros and cons?


This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at

This thread ...


Return to Archive home page | Return to MIDRANGE.COM home page