I’m listening to the Hanselminutes Podcast; \"StackOverflow uses ASP.NET MVC - Jeff Atwood and his technical team\". During the course of the Podcast they are speaking about SQL
SP's are generally used way too soon in the dev process. They should be used when you have a bottle neck sql statement. For example, you probably don't need an SP for deleteing or creating users for an app. For most companys that should be pretty static.
Stored procs are useful for stuff that is not CRUD -- such as specialized, cross-table logic that is best executed in the DB. CRUD operations should not use SPs unless they are the automatically generated output of an ORM tool like TableAdapters.
When you combine SPs with logic with the database itself, you effectively convert the DB in to something akin to an Application Server.
Back when this was the hammer that was most handy, it made a lot of sense. But now with ubiquitous availability of Application Servers, it makes more sense to leverage them for things like centralized logic and business rules and rely on the DB for persistence only.
Some good point make on both sides (as it were) but no-one has made much of the security implication. Wrapping up all DB interaction in SPs means you can lock down the DB so that any interaction with the data can be tightly controlled.
If you think of Encapsulation, you can regard the DB as an object and the SPs as methods and properties that expose the objects functionality to the outside world.
In some larger development environments, UI and Business layer developers aren't allowed near the DB. They specify their requirements and the separate team provides and interface via SPs.
There are some good reasons for not using SPs and some good reasons for only using them - depends on your application and your environment. But rest assured that SPs won't be going anywhere anytime soon.
I might add that some work be better done at the DB level.
e.g. Cross tab results in SQL 2005, Recursive queries.
I agree that some of the simple stuff such as SELECT, INSERT, UPDATE, DELETE can be taken care of by ORM, Linq.
So, it is stupid to say that days of stored procedures are over.
How many people really have to worry about DB platform changes (SQL to Mysql, Oracle)?
I'd say that SPs aren't maintainable and they don't scale. Ask any developer who's had to add functionality to a SP heavy system. Why have half your logic in a different layer? There's nothing to replace, just don't use 'em.
Googled this great post.