Helping ordinary people create extraordinary websites!
| |
Helping ordinary people create extraordinary websites! |
Stored Procedures are EVILBy Tony Marston2006-09-07 
Stored procedures are more efficient
The execution of SQL statements in stored procedures may have been faster than with dynamic SQL in the early days of database systems, but that advantage has all but disappeared in the current versions. In some cases a stored procedure may even be slower than dynamic SQL, so this argument is as dead as a Dodo. Performance should not be the first question. My belief is that most of the time you should focus on writing maintainable code. Then use a profiler to identify hot spots and then replace only those hot spots with faster but less clear code. The main reason to do this is because in most systems only a very small proportion of the code is actually performance critical, and it's much easier to improve the performance of well factored maintainable code. While stored procedures may run faster, they take longer to build, test, debug and maintain, therefore this extra speed comes at a price. If the same function can be performed inside application code at an acceptable speed, what is the advantage of spending more money to make it run faster at a more-than-acceptable speed? It is OK to use stored procedures when you absolutely need a performance gain, but until then they're nothing but premature optimization. Tutorial Pages: » Stored Procedures are EVIL » Stored procedures are not as brittle as dynamic SQL » Stored procedures are more secure » Stored procedures are more efficient » The company has paid for them, so why not use them? » Application code or database code - it's still code, isn't it? » It mangles the 3 Tier structure » Stored procedures are a maintenance problem » Stored procedures take longer to test » BL in stored procedures does not scale » Stored procedures are not customisable » Database triggers are hidden from the application » Version Control » Vendor lock-in » References
|
 |