This is a great discussion. I think there are three camps of technologists here.
1) The DBAs
2) Junior Microsoft developers (typically VB)
3) J2EE developers (N-tier developers)
My experience has been that DBAs are usually proponents of stored procedures. There are two simple reasons for this.. familiarity of database engine and job security.
The Junior developers who typically develop two tier apps prefer stored procedures for performance reasons, because there is usually a big-a*s backend database server which can lift a lot of the data processing load.
Then there are the N-tier developers who are seasoned enough to pick the right architecture. These people prefer non-stored procedural approach. They understand that the database is a persistent store and business logic should be in the middle tier. It gives them flexibility to swap database engines and business logic modifications are localized to the code modules they are working with.
Slashdot Mirror
1) The DBAs
2) Junior Microsoft developers (typically VB)
3) J2EE developers (N-tier developers)
My experience has been that DBAs are usually proponents of stored procedures. There are two simple reasons for this.. familiarity of database engine and job security.
The Junior developers who typically develop two tier apps prefer stored procedures for performance reasons, because there is usually a big-a*s backend database server which can lift a lot of the data processing load.
Then there are the N-tier developers who are seasoned enough to pick the right architecture. These people prefer non-stored procedural approach. They understand that the database is a persistent store and business logic should be in the middle tier. It gives them flexibility to swap database engines and business logic modifications are localized to the code modules they are working with.