RE: SQL vs. traditional I/O?

I rarely jump into these types of discussions, but this has gone beyond the
point of diminishing returns.

Simply put:  if you need to get a dozen or less individual rows from a
table (or tables) and the logical files exits, use traditional I/O.  Its
faster hands down.  Most transaction oriented programs will fare better
with traditional I/O assuming reasonable to good programming practices.  I
think Joe has shown that.  If it is a front end to a web service, sobeit.
The web service does not care how the data was fetched.  That takes care of
graphical vs. 5250 data stream.

If you need to process a significant number of related rows from one or
more tables, use SQL.  It's faster in this case.  More of a batch flavor of
program.  I often mix the two techniques in the same program.  Why not?

The reason Rochester gives us both techniques is both work better than the
other in certain circumstances.  If there was a good rule for when/how, the
case tools would still be around in large numbers and any idiot could
create a program.  Programming requires programmers, folks willing to take
the gobbelty gook some systems analysts crank out and turn it into real
workable code.  That's an art, not a science.  The art here is when to use
the blue broad brush, or the red thin finely tuned brush.  Artist's choice.

Jim Oberholtzer
Senior Solutions Architect
Computech Resources, Inc.