Ronald,
Generally speaking, stored procedures are going to be faster than
dynamic sql. In the case of SQL Server, you might get just as fast
performance from dynamic sql (sql that you generate on the client and
issue to the server, as opposed to executing the stored procedure with
parameters) depending on the cache (dynamic queries are cached to a
degree, and whether or not they are reused depends on how often the cache
is hit, as well as if the queries are the same and a number of other
factors). With stored procedures, the execution plan is already compiled,
and the server won't have to recompile it. Depending on the statistics
that were in place when the stored procedure was compiled, and the
statistics that are in place when you execute your dynamic sql, you might
get a different execution plan (assuming you are executing the same sql
dynamically that you are executing in the stored procedure.
Now LINQ (when coupled with SQL, in LINQ to SQL, or with ADO.NET
Entities with LINQ to Entities) will rely completely on dynamic sql. I'd
expect the sql that is generated to be pretty performant, if issued
against SQL Server, and probably not too much of a difference performance
wise (depending on your load) if you are doing single-statement inserts,
updates, and deletes.
LINQ to objects, LINQ to XML, and anything that works on objects in
memory is a different technology, one which doesn't attach to a database
at all.
Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)
Ronald S. Cook said:
I've always been taught that stored procedures are better than writing
SQL in client code for a number of reasons:
- runs faster as is compiled and lives on the database server
- is the more proper tier to put it since is a data function
But then I've heard that writing SQL in my client .NET code might run
just as fast? Dynamic SQL or something?
And then there's LINQ on the horizon. Is it a successor to everything
previously mentioned?
Thanks for any insight,
Ron