[Dominic Harr]

As you've correctly pointed out, stored procedures are faster precisely because they're precompiled and the SQL engine doesn't have to build a query plan -- it's done in advance, at the time you add the stored proc to the database.

You've never done any DB work, so you probably don't realize that the delay is the actual processing of the data. The DB has to build temporary tables and does all the number crunching in a very, very inefficient manner, processing data relationally.

In an language like C# or Java, you do number crunching in an OO manner, optimized to the specific report to be churned.

For any complex report, the DB will be the absolute slowest way to number crunch possible.

[Bush2000]

The DB has to build temporary tables and does all the number crunching in a very, very inefficient manner, processing data relationally. In an language like C# or Java, you do number crunching in an OO manner, optimized to the specific report to be churned. For any complex report, the DB will be the absolute slowest way to number crunch possible.

That's an interesting straw man, Harr, but it has little to do with anything. Jeeves never said he was doing his report-formatting in the stored procs. He said he's retrieving the basic data and then dumping it into documents on the middle tier. How you twisted that to mean he was doing the reports on the backend tier is a mystery.

[Rightwing Conspiratr1]

In an language like C# or Java, you do number crunching in an OO manner...

Object-Oriented number crunching.
*snicker* Do you even program or are you just in marketing?