RE: SQL vs. traditional I/O?

> From: Reeve
> 
> If your database is fully normalized, and if you want to order sets of
> data
> with some flexibility, you can't beat SQL's ability to create and
order
> the
> records you need.

Hey!  Folks!  I'm not saying SQL doesn't do some things well!  I'm
saying that it is not the right answer for EVERYTHING!

Don't bother countering my examples with a completely different business
issue.  That's not the point.  The point is that there are certain
operations - operations we do ALL THE TIME in business applications -
that are better done in native I/O.

The SQL and JDBC zealots would have you believe that SQL has "caught up"
in performance in every way (that was even implied in this very thread),
and I just don't believe that's true.  And by golly, the very first test
I run and I get a 10-to-1 discrepancy.  I have to admit I wasn't
expecting 10-1, and after a quick change to try and make the test a
little fairer native I/O didn't fair as well.

It only beat SQL SIX-to-one.

And that's just ONE test.  It will be interesting to see just how fast
SQL really is in some of the other tests.  Because I'm actually one hell
of an RPG programmer, and I might just figure out ways to make native
I/O work really well.

Remember, a hammer hits nails just dandy, but that don't mean it's the
right tool to turn screws.

Joe