RE: SQL vs native access (was: Record name the same as the filename)

["Haas, Matt" <Matt.Haas@xxxxxxxxxxxxxxxxxxx>]

<snip>
I have no disagreement with this statement, Matt.  I am not anti-SQL.  I
think SQL is great for set-based operations!  But because I don't think
SQL should replace all native I/O, there are some folks who get pretty
peeved with me and try to paint me as an anti-SQL person.
<snip>

I'll agree with you on this. When I first started working with SQL, I tended to 
want to use it for everything but now I know better. Most of what I do is web 
related so I end up using lots of SQL between the two 400's I work on because 
using DDM files is slow. Like I gave in the example in my last post, I have 
programs that mix native I/O and SQL to get the best performance.

<snip>
Now, the issue about optimization and indexes and all that good stuff -
I understand it's necessary, and I guess my business decision would be
based on whether the amount of time I spent tweaking the SQL statements
was more or less than the time I would have spent doing the same thing
with native I/O.  Because there's no inherent "goodness" of SQL over
native, unless I spread my data over multiple operating systems -
something I'm sure most people would agree is a bad idea, at least for
mission critical data.   Or unless I'm trying to move my application off
of the iSeries.
<snip>

I look at it this way: anytime you start doing things that have to perform 
well, there's always a steep learning curve when you first start out. SQL also 
has the added "gotcha" of being something that looks like it's simple, but in 
the real world, isn't always. The steps you go through performance tuning data 
access in native I/O vs. SQL are really the same (at least at a basic level): 
You need to understand how the app needs the data, design your access paths, 
and then test it out and make changes as needed. The tools you use are just 
different.

Matt