RE: Data access across libraries

Buck, I'm not saying that OS/400 JDBC is bad compared to other JDBC - on the
contrary, the toolbox guys have worked really hard to make it as fast as
possible.  I'm saying that, except for certain classes of queries, JDBC is
not as fast as native I/O.  And, I'm saying that, for CLIENT-SIDE
programming, JDBC binds the client to the physical location of the data,
whereas a true server architecture (be it message-based, or EJB, or a
roll-your-own persistent object technique) completely hides the
implementation details.

JDBC can be a way for bad programmers to hide their lack of programming
ability.  Rather than having to design a database with the appropriate
views, they can simply slap a SELECT statement into any program to get any
field or fields they need.  The SQL programming I decry is the type done
without forethought.  This is NOT a blanket condemnation of SQL or even of
JDBC!  Because Fred brings up a good point: the correct architecture for a
good client/server design is exactly the same as for a good JDBC design.  My
problem is not with the relative minority that know how to design and
implement good, solid SQL designs, but with the vast majority who use it as
a shortcut:

"I forgot about the item description.  Oh well, I can just do a FETCH on the
item master file.  Oh wait, in some cases I need to update the standard
price.  Well, I'll change it to a SELECT FOR UPDATE.  That was easy!  I love
not having to think about my database when I design my SQL programs!  They
can just grow and grow, and nobody needs to know!"

How many abominations of this type have you seen?  Especially in code
"ported" from native RPG to SQL?  Unfortunately, in my experience this has
been the rule rather than the exception, because those who would use SQL as
a shortcut are hardly likely to embrace Fred's concept of a fully
thought-out up-front design.

Anyway, my current final word <smirk> on the issue is that, if you're
designing in Java, the persistence should be in the class, and the idea of a
data source should be introduced, thereby allowing you to switch from
performance (native client/server) to portability (JDBC) as required.

Joe Pluta
www.plutabrothers.com



> -----Original Message-----
> From: Buck Calabro
>
> >JDBC is the single technique most likely to
> >cause the AS/400 to fail as a platform.
>
> Not being a guru and observing from the sidelines, I'm a bit worried about
> this.  My colleagues here and on various mailing lists all seem to want to
> use JDBC since it's the standard way to access the DB.
>
> Is JDBC performance really that bad vs the competition?