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

> From: Haas, Matt
> 
> I guess the point I'm trying to make is that it's very easy to write
> poorly performing SQL and you really need to understand the optimizer
to
> get consistent performance. I will also add that when accessing a
single
> record located on the same machine, it's hard to beat native I/O.

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.

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.

Let's take a great example on the pro side of SQL: I've got realtime
data on my iSeries and historical data on a less expensive Windows
network.  Being able to run a single query over both types of data is a
good thing (and if I recall correctly, you should be able to set up
something where you can actually JOIN the data from the two machines,
although I might be mistaken).

On the other hand, if it takes five native I/O statements to do
something that requires a three-line SQL statement and four hours of
tweaking the optimizer, then am I gaining anything from a business
perspective by using SQL?

I think some people have locked in on SQL as the *ONLY* I/O mechanism
for application development, and it's that particular idea that I don't
like.  But I avoid the whole question.  I prefer to put all my I/O in
service modules, and let circumstances dictate which technique makes
sense for each procedure in that module, rather than spread SQL code all
throughout my application.

Joe