Stored Procedures are EVIL
By Tony Marston2006-09-07
Stored Procedures are EVIL
|
|
A lot of developers are taught to use database stored procedures, triggers and database constraints at every possible opportunity, and they cannot understand why an old dinosaur like me should choose to take an opposite view. The reason can be summed up quite simply:
You only know what you have been taught, whereas I know what I have learned.
I was weaned on file systems and databases which did not have any facilities for stored procedures and triggers, so I learned how to build applications without them. When such facilities became available my colleagues and I still never used them for practical reasons:
- It meant learning a new language, and we didn't have the time.
- It meant taking longer to implement and maintain, therefore cost more to develop. This is an important consideration for a software house which can only win business by providing cost-effective solutions.
- There was no advantage in doing so, so why bother?
Our golden rule was:
Use stored procedures and triggers only when it is an absolutely necessity.
This is in total conflict with the attitude of today's wet-behind-the-ears tenderfoot greenhorn who seems to think:
Use stored procedures and triggers at every possible opportunity simply because you can.
Amongst the arguments in favour of stored procedures are:
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
|
