Is speed really your most important consideration?

I recommend strongly _against_ stored procedures, because I've seen what happens when an application is built around stored procedures, and it's not pretty. In fact, it is my considered opinion that stored procedures are a maintainability nightmare and should be avoided at pretty much all costs.

The number one problem I see with stored procedures is that they are typically used to write application-level logic in SQL. This is very bad. SQL is a data language, was designed to be a data language, and does not do well as a programming language. Yes, it _has_ loops and things, but if you find yourself using them, you're cruisin' for a bruisin', in my opinion. When you start writing application logic in SQL, you get some very ugly code. Sure, it may all be tucked away in the database as a stored procedure, but somebody is still going to have to maintain it. You'll end up with sixty or a hundred lines of stored procedure to do what could be three lines of Perl and a couple of SQL queries. You end up with the next developer who has to touch that bit of code spending three days figuring out how it works first, instead of three minutes.

Second, once you start down this path, forever will it dominate your destiny. Stored procedures will chain you ever more tightly to the specific RDBMS you're using, stealing away precious flexibility that you may wish you had back several years down the line, but it will then be too late. Embedding SQL code in your application (as opposed to using an abstraction layer) is bad enough, but embedding application logic in the database is likely to be absolutely fatal, in terms of your ability later to support another RDBMS.

I do not know who Ask Tom is, but I would run screaming in the opposite direction from this particular advice and take any other recommendation that he offers cum shakero salis.

There are almost always more important considerations than speed. Premature optimization is a root of all kinds of evil, for which some developers, having strayed, have turned away from the truth and pierced themselves through with many sorrows. When your application has a user-noticeable performance problem and you *profile* it and determine that an unnacceptable portion of its time is spent in a certain section of code, *then* you worry about how to make that section of code go faster, and if that means stepping away from the abstraction layer in that place and embedding custom SQL directly in the application, or using a stored procedure, or whatever, then and only then you do that, and you comment it copiously, with details about exactly *why* it's that way.