Comments on: Beating a dead horse: Stored Procedures

By: Business Logic in Stored Procedures is bad! « Rounded Corners

Business Logic in Stored Procedures is bad! « Rounded Corners — Tue, 30 Jun 2009 04:21:49 +0000

[...] Beating a dead horse: Stored Procedures Mind your PQs Stored procedures are bad, m’kay? Good and Evil in the Garden of Stored Procedures Why I do not use Stored Procedures [...]

By: shane

shane — Tue, 28 Oct 2008 03:13:37 +0000

I would say your argument is 100% correct if all you were talking about is CRUD operations – but there is often more to it than that.
There are many times i have had to massage or pivot data requested by an application, and the best way to do that is with a stored proc. There have also been times when business logic needed to be included in the database, this requires a trigger or a stored proc. There are also times when multiple applications need the same data, the best way to effect this is with stored procs.
You have to remember that Linq2Sql is still relatively new, and possibly misunderstood. And not everybody has it (unless the whole world uses .Net exclusively), or has the ability to move to it immediately. I’m sure Linq2Sql would cover maybe 70 or 80% of development needs, but there will always be that 20% that it doesn’t.
I think what you are most pissed at is that people religiously promote the use of stored procs and refuse to consider or comprehend other technologies that could be as good or better – you will never change those people

By: 2008 October 24 - Links for today « My (almost) Daily Links

2008 October 24 - Links for today « My (almost) Daily Links — Mon, 27 Oct 2008 07:09:30 +0000

[...] Ivan Porto Carrero is trying to stop Beating a dead horse: Stored Procedures [...]

By: Abhishek

Abhishek — Mon, 27 Oct 2008 03:42:11 +0000

I remember one of my previous projects heavily relying on Stored Procedures. The prime reason was the kind of database interaction required. Our app server and DB server were in different locations. We required to perform a very data intensive operation based on multiple parameters from client systems. The best approach was to use Stored Procs and it indeed scaled very well. Most of our data oriented logic which required data aggregation from several tables and return back to the app server in specific format was all written in stored procs. Also, another module which required some intelligent snapshot generation of certain part of the table required data to be processed in a complex manner and do segmentation of individual snapshots and store it in staging tables which was to be distributed to the clients based on business logics. I think in this scenario it was a wise decision to go with Stored Procs. So, IMO we can’t conclude that SPs are completely avoidable. We can agree on the fact it should be used in certain situations and shouldn’t be used as one stop solution for each DB interaction.

By: Thomas Hansen

Thomas Hansen — Sun, 26 Oct 2008 14:40:01 +0000

Great writeup, though I didn’t even consider this to be a serious debate any longer myself in fact. I thought this was at the level of “OO is great” and “black box helps maintenance” and such…
Are anybody out there *seriously* using SPs…?
(Except VB6 maintenance guys that is…)
Btw, John Rusk’s comment about MSFT using SPs to “lock people in” I think is a brilliant observation which I didn’t really think was that mainstream (outside of my head that is)
When History is about to be written MSFT has a *lot* to answer for in fact in regards to misinformation like SPs and such…!

By: Clay Lenhart

Clay Lenhart — Sun, 26 Oct 2008 10:18:02 +0000

The Stored Procedure debate is a good one. You may have missed one aspect of security in the debate. If sql server logins can only execute stored procedures, then the actions are limited to the code in those stored procedures. If there are no DELETE statements in the stored procedures, then a malicous user cannot delete anything (or even DROP). I posted exact how to go about this type of security, and in fact, it is very easy to “get right” — ie, you’ll never get a mismatch of code and security constraints (where the code tries to do something that the security constraints do not allow).
http://clay.lenharts.net/blog/2008/01/24/sql-server-security-with-execute-as-owner/

By: Dew Drop - October 24, 2008 | Alvin Ashcraft's Morning Dew

Dew Drop - October 24, 2008 | Alvin Ashcraft's Morning Dew — Fri, 24 Oct 2008 13:19:25 +0000

[...] Beating a Dead Horse: Stored Procedures (Ivan Porto Carrero) [...]

By: John Rusk

John Rusk — Fri, 24 Oct 2008 08:27:11 +0000

PS: Some limitations of LINQ to SQL, when working with stored procs, are noted here: http://oakleafblog.blogspot.com/2007/09/problems-using-stored-procedures-for_08.html Apparently using stored procs adversly affects LINQ to SQL’s change tracking and lazy loading.

By: John Rusk

John Rusk — Fri, 24 Oct 2008 08:19:28 +0000

Hi Ivan,

I agree with you.

By the way, I think this comment from Frans is arguably even better than the article you link to above: http://www.theserverside.net/news/thread.tss?thread_id=31953#158113 He begins by describing two different kinds of stored procedures, and explaining that one is OK and the other is not. I think he describes it very well.

To me, a key to any real progress on this debate is some correct and meaningful guidance on it from Microsoft. They’ll need to make it clear to the community that they are putting aside any self-interest they may have in locking developers into the SQL Server plaform (as is the result when using T-SQL) and instead give comprehensive and accurate advice. For instance, there is no use in making outright incorrect statements in widely-read guidance (see http://dotnet.agilekiwi.com/blog/2008/08/practical-step-in-stored-proc-debate.html )

By the way, I raise the point about the need to explictly put aside self interest because I’ve heard, more than once, that Microsoft give biased advice on this topic to promote lock-in to SQL Server. If that’s true, it needs to change. It is inconsistent with Microsoft’s increasingly open approach in recent years. If its false, then MS should demonstrate that it’s false.

The good news is that Microsoft are currently writing a new draft of their guidance, and it is fully open for community feedback on CodePlex. What we need is for everyone who’s concerned about this issue (and other aspects of .NET arhitecture) to get over there and leave comments and/or add items to the “Discussion” tab.

Here’s an intro to MS’s new guidance, from an ALT.NET perspective: http://codebetter.com/blogs/jeremy.miller/archive/2008/09/11/p-amp-p-architectural-guidance-version-2.aspx