Stored Procedures - End of days

Question

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

Answer 1

On modern systems, parameterized queries are compiled and cached at the server, so they're just as fast as a stored procedure. They have most of the same security features as well.

For databases that serve a single application, it makes more sense to have the query logic there at the relevant location in the code. If nothing else it makes it easier to do source control. If you keep stored procedures on the server keeping track of them can quickly become a mess. Additionally, if you're using an ORM tool you may not have much in the way of real SQL anyway.

If your database serves several different applications, then you may still want to use stored procedures to enforce business rules between application.

Answer 2

Stored Procedures / Views / Functions are still a good "Interface" to the database if you are running multiple enterprise applications sharing the same database.

App#1 - You need to add a new relationship/field, or change a nullable column to non null.

App#2-10 - May or may not use this database object

The first thing I want to do is check my database object dependencies to determine how its used and if I'll break anything. Well, guess what, if you have a bunch of external queries VIA ORM / SQL you would have no idea of the dependencies.

This is the only drawback I found having direct access to tables.

For a single application using single database, this really isnt an issue. Although you still have to look at the application code for dependencies in addition to the database.

Answer 3

Judging from the lackluster performance of this site, I'm going to wager the major bottleneck is the database.

I'm not convinced in any way that the LINQ 2 SQL ORM they are using is one bit faster than a sproc.

Answer 4

Part of this is driven by the availability of non-relational datastores. SPs generally imply a relational database; ORM and Linq offer the the ability to create abstraction layers that are richer than SQL offers, and sometimes a better match for the abstractions we use in other parts of the design (the "impedance mismatch" problem.)

And it can also be considered a function of architecture. SPs imho match pretty well with a classical table-driven application, and can provide a convenient way to architect an abstraction layer at the business-objects level.

They're not so handy if your data store is xml, or an analytical database.

Answer 5

maybe i'm too old-school, or too lazy, or both, but i have to disagree. Time and again stored procedures have 'saved the day' because when a minor back-end change or bug appears we only have to fix the stored procedure instead of updating the desktop application on several dozen desktops plus the web server. In addition, the users are not interrupted. This saves a great deal of effort and user hassle.

In addition, some DB operations are just going to be more efficient on the server rather than going back-and-forth across the network, esp. when one stored procedure calls another which calls another etc. (with or without cursors)

EDIT: in a SOA architecture the update-the-client-apps issue is mitigated (thanks maud-dib), but stored procedures calling each other is still more efficient than multiple network round-trips to the SOA layer. And updating the SOA layer is not always trivial either.

Answer 6

It also depends on what your stored procedures are doing.

For example if it's just

select a from b where x = y

then a stored procedure is probably overkill. But I personally tend to use stored procs to return multiple result sets and page results within the database.

In my cases I can see a benefit to using them. It is an extra layer to deal with but if you have your code well organised and logical I don't see too much hassle personally.

A good project with stored procedures is always going to be better than a shoddy project without and vice versa.