Oh man, as a dba, I can't help but reply :) There are some things you simply can't do efficiently unless you do it on the DB. I think too often people get afraid of being forced to stick with one DB, when in reality you probably wont switch anyway. Since the Db is actually interpreting the TSQL code being thrown at it and making its best guess about how to use indexes, etc. stored procedures are particularly useful for forcing a compiler to work one way or another. In addition, with large tables, or queries that require complex logic, you simply cannot do it on the client side with any efficiency. I feel better :) -B PS: I love this example.. Most people aren't aware that the join order can effect the query time. 1) Take this query. Select * from large_table lt join small_table st on lt.id=ct.id 2) On most RBDMS systems you can make it more efficient by simply switching the join order. Select * from small_table st join large_table lt on lt.id=ct.id
on 2006-03-17 18:49
on 2006-03-17 19:58
Well, :o) I'm not going to send us into a fracas, especially considering I'm talking to a dba here ;o) and you're thoughts on the matter are influenced by being a dba. We'll just have to agree as gentlemen to disagree. lol I haven't see much I couldn't do efficiently on the middle tier. As stated in my previous posting, we supported three or more database engines simultaneously. Having a bunch of processing done in stored procedures just doesn't work for us as a result. Could you give examples of what is done more efficiently on the database server? We didn't run into complex queries as you describe. We just stuck with the KISS principle and things worked fine.