RE: SQL vs. traditional I/O?

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> From: Walden H. Leverich
> 
> Fair enough (unless you have _really_ big orders. But how about just 8
> rows per order, and 15 orders on the screen? List 15 orders in a
> subfile, and for each total the 8 rows. Bet SQL still wins.

You might be right.  But after today's results, I'm not betting the
house.  This is the sort of thing we're going to test QUANTITATIVELY on
the IAAI website.  I'm tired of guessing.

But even if SQL proves better on that sort of thing, that's just one
class of operations.  Heck, I already believe that as queries get more
complex SQL tends to win out, simply because more and more is done under
the covers closer to the bare metal.  But that doesn't mean you throw
out the baby with the bathwater.  As you say, the beauty of our platform
is that we can indeed do both.  So why not have SQL for queries and
native I/O for row-based processing?  Why force SQL to do things it
wasn't meant to do and frankly isn't very good at?

> >you'll learn how to say Java is not good for all things
> 
> I'm a MS guy, I already say that <G>

Yeah, I thought about that after I sent it <grin>.

> >and eventually, you'll even learn to say that Windows is not good for
> everything.
> 
> Um, it's not??? <G>

Ah, some are sicker than others...  <smirk>

Joe