RE: SQL vs native access

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> From: Jon Paris
> 
> 
> Joe, Paul Conte did a very comprehensive set of tests a few years ago
for
> News.  Should be on their web site somewhere.  In the article he
described
> the testing methodology etc. and I think possible optimizations.  Why
not
> at
> those sources for test cases?

Thanks, Jon.  This sounds like a good starting point.  But then again,
I'm not a "real" member either, so I could be SOL.


> PPS.  I do know that performance is a very frustrating issue for the
SQL
> guys since it is all but impossible to improve SQL performance without
> also
> improving native performance.  They are therefore chasing a moving
target!

Okay, this brings up an interesting point: why is it frustrating?  Do
the SQL guys want to be "better than" native I/O?  Common sense would
indicate that the extra overhead of SQL will ALWAYS make it a little
slower for single record operations, but that it's set-based
capabilities will make it faster for set-based operations.

It seems to me that the best of all worlds is a completely encapsulated
database access module that uses SQL for set operations and native I/O
for single record operations.  Then you'd have the best of both worlds,
and the application wouldn't care.

But hey, that's just me.

Joe