Peter said:
I guess its all a matter of personal preference really. I think the
general consensus that the best practices is to use stored procs.
no, it's a myth that stored procs are 'better'.
The advantage of stored procs is that they're compiled (I believe), and
no they're not compiled, at least not on SqlServer. On DB2 they're
generated as C code which is compiled but on SqlServer and also on
Oracle, they're not compiled, but stored as is and when executed they're
compiled and the EXECUTION plan is cached. The same is done with a
parameterizied query. This means that the second time a parameterized
query is executed, it's cached execution plan is used, it's not recompiled.
hence run much faster than a query passed in a string. Plus as they are
doing mainly direct database actions it makes sense that they sit
within the database server.
Only if they are not used for CRUD operations. Procs for CRUD are more
of a burden than a help. Long running data munching procs are better
suitable in procedure form in the database, however not a lot of systems
needs these.
However, if you are doing many calls to the db server, it may make
sense to wrap the query up into one string and pass that, as the db
server round-trips can be a bottle-neck.
Also, stored procs don't have source control, unlike c# code can have.
Most DBA's write their scripts first in textfiles and store these in
sourcecontrol
Frans
--