RE: Calling DB/400 gurus - where to put DB keys physical or logical?

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> From: R. Bruce Hoffman, Jr.
>
> Also, keep in mind that indexes are tuning points and not access
> points for
> SQL. As we move more towards SQL environments and make more use of RI,
> logical files become essentially irrelavent for data CRUD operations.

This takes for granted the move towards SQL and RI.  Those of us who believe
in server-encapsulated I/O would differ.  So why use servers?

1. It's more OO - the contents, structure and even location of the data is
hidden from the user.

2. More involved data integrity - "if references exists, mark the record as
soft deleted, otherwise hard delete the record", or, "when all allocatios
are zero, set the allocations flag to blank".

3. Business logic stays in one place - with RI, you have to code some of the
rules in an HLL (even SQL) and some in your RI language.  You have to
maintain your contraints.  While fairly simple today, as RI gets more
sophisticated (which it must to handle the situations in point 2) that means
more little pieces of code littered throughout the system.

4. Servers can still be accessed via SQL, as stored procedures.  This gets
rid of the "platform independence" issue.

5. Finer grained security - a server can provide much tighter row and column
level security, using flexible data driven rules rather than hard-coded
access.

These are just a few reasons to at least consider servers.  On the pro side
of SQL access, it allows ad hoc access to the data.  Some people think
that's a good thing.  Personally, I don't like people traipsing through my
database without my knowledge and I absolutely can't stand them updating it.

So I guess my personal view is that, under controlled circumstances,
read-only SQL access makes perfect sense.  All other database access should
be firmly encapsulated in servers.  If you want to write your servers in
SQL, more power to you.  If you want to use RI, great.  But most access, and
certainly all update access, should go through a server.

And me, I'm going to write those servers in RPG, not SQL.  As the RPG
language matures, its expression handling capabilities make it more and more
capable as a language for defining business rules using a readable syntax -
c ertainloy more readable than smoe of the tortuous SQL statements I've
seen, while at the same time providing a highly efficient interface from the
HLL to the database.

Why all this typing?  Well, because I wanted to point out there are
alternatives to the SQL juggernaut.  If SQL and RI are your direction,
great, but those of us who like servers still want RPG and logical views,
thank you very much.

Joe