RE: Data access across libraries

>Take a representative number of your files (master files,
>transactions, history, etc.), stick them in the DB on the
>$2000 PC and have then run a hundred simultaneous queries
>and updates against large numbers of records.
>Then do the same on the $100,000 system.  I think you'll
>find that the $100,000 system copes a lot better with the
>load -- but you knew that didn't you?

Yes sir!  Again, I managed to misstate my main idea.  I should go take a
class in writing!  My point is that thousands of recent university graduates
are indoctrinated that JDBC is THE way to interact with a database.  That's
apparently in the syllabus.  What's not in the syllabus, and therefore
learnt by implication, is the idea that cheap PC's do this work Very Well.
They seem to pick up that idea mainly because they've worked against small
databases.  I remember the look on one fellow's face when I explained that a
typical telephone call record transaction file contains some 20 million
records per month.  The biggest table he'd seen to date was some 5000
records.

It's this unspoken understanding that JDBC works quickly and efficiently
with cheap hardware that's shooting us down.  When you mention large
databases to them, they answer with a flip "add more servers."  I'm not
going to travel too far down this road in this list; pretty much all of the
posters here are already using the 400 and don't need to hear the same story
again.

>Although I'm a firm believer in the idea that the
>data should be managed at the database and that
>means few or no raw queries in client code,
>just SQL CALLs to stored procedures.  I don't
>care if the stored procedures are SQL,
>embedded SQL, or native I/O.  Certain stored
>procedures may not be portable but then you chose
>your database for many reasons and portability
>should be pretty low on the list.

Indeed.  Our DB is on the 400 because it was the best machine for the job
"way back when."  Now we have lots of RPG code that talks to that DB, but
the DB isn't completely normalised, nor is it really ready for triggers and
RI rules.  None of the existing RPG code knows how to handle disk I/O errors
(RI violations.)

The "portability" issue is the Java mantra.  All I care about is that the
Java people seem united in their desire to use JDBC to reach the database.
Regarding raw SQL vs. stored procedures, we have a (probably typical)
situation where most or all of the database integrity is enforced by
application code.  We're very slowly migrating some of that "pseudo RI" into
stored procedures to be used by the RPG and by stored procedures (write
once, reuse many times).  We're just not there yet.  It's an ongoing
process.  Market forces being what they are, our client code MUST contain
raw SQL just to deploy it quickly enough.

Nobody thinks this is a good thing, but there isn't a whole lot we can do
about it.
  --buck