Possible Duplicate:
What are the pros and cons to keeping SQL in Stored Procs versus Code
I was listening to Hanselminutes podcast “Rise of The Micro ORM,” where one of the guests (Sam Saffron and Rob Conery) outlined the classic reasons that DBA’s insist on stored procedures:
- They are pre-compiled, which gives them an execution speed advantage
- They hide the underlying database scheme, which allows a separation of interface and implementation that prevents brittleness.
A guest then said these aren’t good arguments, and suggested the real reason the DBA’s will insist on stored procs is because they simply want to protect themselves from the ignorance of the middle-tier developers.
I found that statement to be a bit on the extreme side. Certainly I can agree that argument #2 is flawed, but I thought it was well known that sending arbitrary (uncompiled) SQL to the database was a performance hit. Is there something I’m missing that would explain why argument #1 is not really true?
My own answer, as just a guess, is that there is a performance hit – but it rarely matters. It is perhaps analogous to a developer who attempts to optimize every loop he writes, even though only 1% of the loops written ever benefit from the tuning. Am I capturing the thought correctly?
“but I thought it was well known that sending arbitrary (uncompiled) SQL to the database was a performance hit.”
The distinction you’re making between stored procs and other sql statements regarding precompilation hasn’t existed since SQL 6.5.
http://msdn.microsoft.com/en-us/library/aa174792%28v=sql.80%29.aspx