Re: Pros and Cons of DB defined Referential Integrity Constraints

On 18 Oct 2012 15:26, Ken Sims wrote:

On Thu, 18 Oct 2012 13:05:45 -0700 (PDT), Nathan Andelin wrote:

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.

I think that's big one right there. The DB constraints not only
apply to the regular application programs running on the i, but also
utility functions such as STRSQL, DFU, DBU, etc. and remote
functions such as ODBC and FTP. (Actually I don't know that it
applies to FTP but I sure hope it does!)

All interfaces above the LIC have a limited set of methods that can be performed against the data; as with methods for objects. Even the OS [database] code which provides interfaces to these methods, to the languages, utilities, the SQL, and CL commands, can not bypass an enabled constraint; system, object, and data integrity demands that. So just like a user or application, only by removing or disabling the constraint will the RI protection no longer be enforced. Consider that even if the visible implementation of the constraints [e.g. visibility in DSPFD and\or the catalogs] mysteriously disappeared, the LIC database is still going to enforce the rules. If anything can be found that defeats the enabled constraint rules, other than either the SST D/A/D which is a service interface available to bypass some method restrictions or similar binary alterations of a *SAVRST copy\version of the data, then something would be wrong.