MIDRANGE dot COM Mailing List Archive

Home » MIDRANGE-L » October 2012

Re: Pros and Cons of DB defined Referential Integrity Constraints



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

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

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact