"Chris Wolf" schrieb
[Nested Recordsets/Resultsets as an alternative to Joins,
to "shape-off" redundancy in "hierarchical requests"...
as a native DB-Feature usable over Sybase StoredProcs...
...and the ADO-ShapeProvider as an example for an
alternative to use "these things" in a DBEngine-independent
way (at least on the Win-Platform)]
> > If you request the construction of such a nested
> > Recordset at the serverside (over the Shape-
> > Provider), then there are no network-roundtrips
> > involved, in case the DB-Server and the
> > AppServer do run on the same machine.
> >
> > But we digress ... ;-)
> >
> In your scenario, here, even though the middle-tier
> ("business-layer-code") is collocated with
> the database, it looks to me like ADO is still a client-server
> technology (I'm relatively unfamiliar with it) you still need
> a "Connection" object to connect with the database, ...
You're basically right - ADO-Resultsets are the "storage-
container" (with an integrated Cursor-Engine), that
"looks always the same" to your Application-Code -
and the "ADO-Connection-Object" connects (involving
the OLEDB-driver) to the DBEngine in question.
And in case the DBengine runs on the same machine as
the OLEDB-Driver, then faster IPC-mechanisms
(than sockets) are usually involved.
> ...so I assume there's still a protocol stack, through which,
> the client-based "SHAPE" mechanism must make multiple
> (local) round trips.
The "protocoll-stack" is thin in this (local) case - but if
you want to put it this way, then yes - the SHAPE-Provider
will probably perform "multiple Requests" - how efficient
it does this (compared with "native Sybase") would need
to be tested.
At least I could imagine some Optimizations (working
over Joins, which include only the Parents Primary Key
in the Joined result, to avoid overboarding redundancy,
before the final Resultset is constructed and delivered
into the "hierarchical ADO-Recordset-container".
> Even though the ADO Connection is not as heavy-weight
> as HTTP, or even TCP/IP (I'm assuming for local connections
> it may be via named pipes) ...
...or Shared Memory...
> There's still serialization/deserialization of the client-server
> protocol stack.
No, would not think so - since most OLEDB-providers
(as well as the ADO-Recordsets) also support so
called "serverside cursors" - the "looping over incoming
records" can be done efficiently "in place", building the
hierarchy "on the fly" then (no larger buffer-conversion
or -swapping going on IMO).
> With stored procedures, the multiple open cursors to different
> tables are right there, running in the same process/thread
> space of that stored proc - no connection, no protocol
> stack, so it's going to be "much" faster.
I would not bet on your "much"-attribute that much... ;-)
After all there is an overhead of course - but the DB-engine
itself will need a larger amount of time internally, to perform
the "joining" (the key-lookups on the dependent tables).
How much faster native Sybase is, compared with the more
generic "ADO-Shaper" ... only a test can tell (in case you're
running on windows, this should be relative easy to do).
But the general point you made is understood I think -
Stored procedures, which do make use of builtin
specialities can (or better: usually) offer a better performance -
the question is, "how badly" an application is in need
of that advantage (or if it is large enough, to be noticable
at all).
Olaf
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
