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

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> From: Buck
> 
> As usual, I didn't make my point very clearly.

Hee hee!  Buck, you make your points fine, just sometimes I miss the
nuances.  And in fact, after I posted my statement, I reread yours and
said "Wow, he means that SQL performance is highly data-specific".

That of course is a very scary proposition, because it means that what
works one day may change drastically if your database makeup changes.
For example, a merger might change your data demographics enough that
you would have to revisit a significant part of your SQL that was
working just fine before.

Of course, data changes of that magnitude affect everyone to a greater
or lesser degree, but evidently the degree is much greater for SQL.  And
I guess that makes sense, since almost by definition the "optimizations"
performed by SQL are really codification of assumptions about your data.

Then again, you can make assumptions with native I/O that are affected
by radical changes in the database.  I guess it's just that SQL
performance is so dependent upon the optimizations that when the base
assumptions are incorrect, the performance impact is more severe.  But
I've seen bad assumptions in native I/O programs that have had some
severe performance problems as well.  There's one in particular back in
BPCS 2.1 that had to do with a sequence number - man was that one ugly.

So the upshot of the story is that performance is an issue that needs to
be addressed on a one-off basis regardless of your architecture, but it
can be harder to directly translate performance techniques from one
machine to another when using SQL.

Joe