RE: SQL vs. traditional I/O?

> From: Walden H. Leverich
> 
> You're doing row-at-a-time processing, you're just using SQL to do it.

Yeah, but that's what business applications do, Walden.  This is my
point.

> Add a "Order Total" field to your 800K row table. Then write an RPG
> program that reads the rows and sums the order total. Try that against
> "select sum(OrderTotal) from file" and see which is faster.

Probably SQL, Walden.  But it just so happens that I rarely have to add
the order total field from 800,000 records.  I'll be the first to admit
that there are things SQL is good it.  It just so happens that
single-row fetches are not one of them.

> The fetch operation, while important, is in SQL so SQL can act like
> classic IO. It's not what SQL is good at.

You win the big cupie doll, Walden.  There are entire STACKS of things
that SQL is not good at, this is just one of them.  The problem is that
many applications require just the sort of processing that SQL is not
good at.  And thus, by extension, those applications are not good
candidates for SQL.

It's good to at least hear you say that SQL is not good for some things.
Later on in our self-help program you'll learn how to say Java is not
good for all things, and eventually, you'll even learn to say that
Windows is not good for everything.

Admitting is the first step to healing.

Joe