|
Helping ordinary people create extraordinary websites! |
Stored Procedures are EVILBy Tony Marston2006-09-07
Vendor lock-in You may think that this is not a problem if you build and maintain the applications for a single company where a change in database vendor is highly unlikely, but what happens should the company decide that their DBMS is no longer flavour of the month and they want to change to a different DBMS? This may be due to several factors, such as spiraling costs or poor performance, but when it happens you will find that a lot of code will have to be rewritten. Porting the data will be one exercise, but porting the stored procedures and triggers will be something else entirely. Now, if all that logic were held inside the application, how much simpler would it be? Believe it or not there are people out there who write applications which are database-independent for the simple reason that the applications may be used by many different companies, and those many companies may not all use the same DBMS. Those that do use the same DBMS may not be using the same version, and stored procedures written for one version may not be compatible with another. As far as I am concerned the use of stored procedures, database triggers and foreign key restraints is OPTIONAL, not MANDATORY, therefore I am free to exercise my option not to use them. That is my choice, and the software that I produce does not suffer in any way, therefore it cannot be defined as the wrong choice. The web application framework that I have built using PHP does not use stored procedures, database triggers or foreign key constraints, yet it does not suffer from any lack of functionality. This is possible simply because I can do everything I want inside my application where it is instantly accessible and customisable. To those of you who instantly jump to the (wrong) conclusion that this must mean that I have to write a huge amount of duplicated SQL statements my answer is simple - I don't write any SQL statements at all, they are all generated dynamically at runtime. This is all due to the framework being built using the 3 Tier Architecture which has a clear separation of concerns:
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 |
|