RE: Use of DB2 constraints

> But, in a world where update access to data may no longer be
> exclusively controlled through RPG application code, some kind of
> change will eventually have to happen. Especially if we want to
> insure the data integrity of our shared databases.

Personally, I think the idea of allowing unregulated external update access to 
your database in any way is an incredibly poor idea.  All databases should be 
locked down without any sort of unsupervised external access.  Constraints and 
triggers are one way, though they have certain limitations.  Personally, I 
prefer putting server programs around every database file and limiting access 
that way.

Even with triggers or constraints, though, I think ODBC update access (either 
through SQL or JDBC) to your files is an incredibly bad idea and should be 
disallowed before anyone thinks to use it.  ODBC read access is bad enough; it 
locks your clients into the structure of your database (or perhaps vice versa), 
making it impossible to change the physical layout or location of your data 
without impacting client systems adversely.  ODBC update access simply 
compounds the problem.

A message-based client/server architecture, OTOH, allows complete autonomy of 
the database, allowing you to even support versioning, where an older, 
out-of-date client can still be allowed deprecated access to the database for a 
predetermined period of time, even if the files are physically relocated to 
another machine.  It's very difficult to allow this sort of independence with 
either a triggered or constrained database accessed via ODBC.

Joe



+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---