RE: SQL vs. traditional I/O?

[rob@xxxxxxxxx]

Some points.

I really suggest that one purchases a good book on SQL and read it
cover-to-cover.  Don't skip the basics.  Even if the first chapter has
basic discussions like "What is a file, record, member?".  I used "SQL/400
Developer's Guide" by Paul Conte and Mike Cravitz available at:
http://store.midrange.com/
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.

Joel brings up an interesting paradigm.  Try to imagine, with an open mind,
why you would really need a single row fetch, in traditional or
SQL.  Sometimes it's a good exercise to stretch the mind.  Here's a
sample.  "Hey, I need a single row fetch to make sure that the item number
is valid before I write this order detail record."  Couldn't this be better
handled by putting a referential constraint on the file?  You may end up
still using it, I'm not arguing that point.  Just asking you to stretch the
mind.

Good timing sample Joe.  I wonder about the record blocking or caching
also.  If this was a real world sample, I'd explore that hypothesis.

I'm concerned about statements that you to have everything just right in
order to get SQL right.  I would say that this applies to traditional just
as well, if not more.  I've seen some convoluted code that would boggle
your mind.  Like someone who didn't know what a SETLL/READ combo was in
RPG.  They actually used a goto loop for every possible line number
associated with an order.

While you can do some awesome things with join logicals, (I'm quite proud
of one with 10 files), I think SQL really allows you to go the extra mile
with views.  Some people get a testoster_one rush from keeping people out
of end user query tools (up until the time the users throw the server out
and go with one where they can have access to those tools.)  But, with
properly constructed views you can really make users Query's much
easier.  And less likely to do stupid performance killing things.

Gosh, there was one more point, but I forget it now, dang.


Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com