RE: SQL vs. traditional I/O?

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> From: rob@xxxxxxxxx
> 
> Not picking on you Joe, just using it as an example.  But using a
cursor
> for a single record fetch is an example that education needs to be
done.

Rob, I'm willing to say off the bat I'm no SQL expert.  But you'll
notice that even with the SQL experts chiming in, native I/O is still
outperforming SQL by a WIDE margin, despite implications to the
contrary.  And frankly, I think there are SQL experts who don't have a
clue how to write native I/O, and that's why they shy away from it.

The whole idea of the IAAI site is to get some real numbers in place, so
that architectural decisions aren't colored by opinion or FUD.  Then we
can begin to expand the scope to finding new models and new ways to
think.

There's one other crucial point here.  While you're right that there are
bad programmers in any syntax it's my contention that, at least among
the midrange crowd, there are more people who can debug and optimize a
native I/O algorithm than there are those who can optimize SQL.  SQL
seems to lack a basic level of understanding.  Look at the responses
we've gotten here: some have helped, others have not.  Some of the
suggestions don't even compile.  That's the scary part of SQL: the lack
of real knowledge.

Hopefully the website will help in that regard as well.  I think it
would be really cool to be able to go to one place and find examples of
code with timings to see which approaches best handle which
requirements, as opposed to the rather haphazard "try this, it might
work" which seems to be the hallmark of many of the newer technologies.

That being said, I'll try to take you up on your suggestion and get my
hands on a good SQL book.  But I'm hoping that as the site progresses
that the SQL experts out there will lend a hand, and that way no one
person has to be the expert in every technology.  Isn't that the whole
idea behind Open Source and component programming? 

Joe