Additional thoughts regarding using Stored Procedures: SQL Injection: Stored procedures can help stop injection attacks, but you can also do it with parameterized queries. I would rate this as a wash.
Development Speed: Stored procedures slow down development in large environments where there is a separate DBA. I recently worked a contract at MD Anderson and burned a good week trying to get the DBA to, correctly, modify some SPs. Not to mention, if the same person is the DBA and the programmer they now have to know two different syntaxes. MVC: SPs mangle the three tier architecture designed for apps. Instead of having a structure which separates logic from storage, you have storage and logic on the same tier. This will almost certainly cause problems at a future date - unless perhaps the DBA is very good and not overworked - and doesn't leave the company. Business logic in a SP does not scale: Business logic should be in code and not in the storage center. When you have multiple database servers, it is more difficult to keep the triggers and SP’s synced. Also, there is no version control for SPs and database screw ups can be very dangerous. Processing Speed: I was wrong about the speed issue also - it now looks like that even dynamic SQL is just as fast using parameterized queries. Migration: I was recently given the argument that using SPs made sense if there were plans to migrate to different middleware (in this case from CF to asp.net). That made sense for a minute but after I thought about the statement it seemed to me that it was just an easier method of getting yourself into a bad long-term situation. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the "Houston ColdFusion Users' Group" discussion list. To unsubscribe, send email to [email protected] For more options, visit http://groups.google.com/group/houcfug?hl=en -~----------~----~----~----~------~----~------~--~---
