Re: Pros and Cons of DB defined Referential Integrity Constraints

Nathan,

In my college COBOL class one of our first programs was to validate each
field. Was the numeric, numeric and that sort of stuff. However, who
nowadays checks to see if a system defined numeric field is numeric? Very
rarely needed. Unlike in the day of taking a long character field from an
external source and putting it into individual fields. (ok, maybe this
still happens but this isn't what I am talking about.)

On the other hand, I see your point. If I write to a transaction file,
let's say a log file. And this log file contains: Order number, item
number, item class, salesperson number, etc and most, if not all, of these
have RI constraints. Now, lets say 2 or more are missing: invalid item
number for example. On the write I will get an error (in RPG %error) then
I'd have to analyze the log to see what error(s) occurred. Sounds "new"
when I may be more familiar with prechecking data and handling it that
way. And, to many, "new" is to be avoided. However I'd argue that if
more people were more familiar with doing it this way then it would be
easier to upgrade packages. For example if my ERP package already did
this then if I added a RI constraint, or a check constraint the existing
program logic would catch it with no further modifications. (sure,
highlighting a field in error in addition to a message at the bottom of
the screen would be nice, I'll grant you that)

Rob Berendt