Stored Procedures?

I read the excellent thedailywtf.com for Alex Papadadimoulis’s supreme combination of irony and wisdom when it comes to scrutinizing real-life examples of questionable code — usually code that takes some-or-another methedology or technology to an absurd extreme. (Great examples of XML-overkill, Enterprise-overkill, OOP-overkill, etc.)

While sometimes the site can serve as a tremendous ego-boost to the self-doubting programmer, more often than not I use thedailywtf.com to scrutinize myself — I was first referred to when I was trying to justify the use of a Factory-factory in PHP. (Although after having read the relevant article I still think I was justified, even more so having found a poster that aggreed with me.) (But of course, the internet is good for finding justification for anything, isn’t it?)
Sometimes — but not always — there is useful insight in the 100-or-so comments that follow a posting. Today I enjoyed reading some anonymous poster’s insights on Stored Procedures. He or she articulated my current perspective better than I could have (something else the internet is good for):

Wow, trying to keep application logic out of a database is the *stupidest* thing you’ve ever heard? If there is one property of “enterprise” applications, it is the fact they are often systems that deal with many data sources and services, often performing logic between the disparate sources. But lets list some reasons to keep the logic out of the database.

1) Stored procedures tie you to a particular vendor
2) Application logic in the database has to duplicate logic in the application
3) Horrible source code control (in every case I’ve witnessed)
4) Lack of OO design, hence the term “stored PROCEDURE”
5) Difficulty migrating to a different database vendor/version
6) Puts load on the database, which doesn’t scale/cluster well since it is the data source of record

Instead, put the logic in your objects, keep the database as minimal as possible, and certainly use a good persistence tool to ensure the updates and queries are correct.

I admit, you can instaed take a very data-centric view of things, and many people successfully work under the idea that the database *IS* the application, and everything else is just a GUI/front end. But this is not very scalable, not Object Oriented at all, and IMHO is only suitable for smaller systems, and certainly not large “enterprise” ;) systems. All these points can, of course, be debated…

But wow, this is the *stupidest* thing you’ve ever heard!?! WTF!!!

Thanks Alex, thanks Anonymous.

Leave a Reply

*
To prove that you're not a bot, enter this code
Anti-Spam Image