Understanding the architecture of your database engine is important. I've had numerous "I told you so" moments in my career when devs didn't believe me, and whe

Understanding the architecture of your database engine is important. I've had numerous "I told you so" moments in my career when devs didn't believe me, and when ahead and do things like: a) Let's speed up the SQL processing by creating 40K connections and each connection running a stored procedure. Unless your particular SQL instance has enough memory and cpu to support 40K connections, you are performing a denial of service attack on your own server. b) I hate stored procedures and scripting; I am going to write a big ass SQL query that is 200 lines long. Your giant SQL query is too complex for the SQL engine to create an optimize query plan. It will effectively reduce your database engine from using set based logic to one row at time. One time, a developer complained SQL sucks and blow big time blah blah blah. It took me four hours to figure out his ungodly query. I was able to performance tune the query by breaking it into many small steps using temp tables and putting it all into a stored procedure. Execution time improved from 10 minutes to 9 seconds.