Дали да използвате съхранени процедури или не е по-скоро религиозна или политическа дискусия в бар, отколкото не.
Това, което трябва да се направи, е ясно да дефинирате слоевете на приложението си и да не прекрачвате тези граници. Съхранените процедури имат няколко предимства и недостатъци пред извършването на заявки извън базата данни.
Предимство 1:Съхранените процедури са модулни. Това е добро нещо от гледна точка на поддръжката. Когато във вашето приложение възникнат проблеми със заявката, вероятно ще се съгласите, че е много по-лесно да се отстранят неизправности в съхранена процедура, отколкото при вградена заявка, заровена в много редове на GUI код.
Предимство 2:Съхранените процедури са регулируеми. Като имате процедури, които обработват базата данни, които работят за вашия интерфейс, вие премахвате необходимостта да модифицирате изходния код на GUI, за да подобрите производителността на заявката. Могат да се правят промени в съхранените процедури – по отношение на методи за присъединяване, различни таблици и т.н. – които са прозрачни за интерфейса на предния край.
Предимство 3:Съхранените процедури абстрахират или отделят функции от страна на сървъра от страна на клиента. Много по-лесно е да кодирате GUI приложение, за да извикате процедура, отколкото да създадете заявка чрез GUI кода.
Предимство 4:Съхранените процедури обикновено се пишат от разработчици/администратори на бази данни. Хората, които изпълняват тези роли, обикновено са по-опитни в писането на ефективни заявки и SQL изрази. Това освобождава разработчиците на GUI приложения да използват уменията си върху функционалните и графични презентации на приложението. Ако вашите хора изпълняват задачите, за които са най-подходящи, тогава в крайна сметка ще създадете по-добро цялостно приложение.
Имайки предвид всичко това, има няколко недостатъка.
Недостатък 1:Приложенията, които включват обширна бизнес логика и обработка, биха могли да натоварят прекомерно сървъра, ако логиката беше внедрена изцяло в съхранени процедури. Примерите за този тип обработка включват трансфери на данни, обхождане на данни, трансформации на данни и интензивни изчислителни операции. Трябва да преместите този тип обработка към бизнес процесите или логическите компоненти за достъп до данни, които са по-мащабируем ресурс от вашия сървър на база данни.
Недостатък 2:Не поставяйте цялата си бизнес логика в съхранени процедури. Поддръжката и гъвкавостта на вашето приложение става проблем, когато трябва да промените бизнес логиката на езика Sp. Например, ISV приложения, които поддържат множество RDBMS, не трябва да поддържат отделни съхранени процедури за всяка система.
Недостатък 3:Писането и поддържането на съхранени процедури най-често е специализиран набор от умения, който не всички разработчици притежават. Тази ситуация може да създаде тесни места в графика за разработване на проекта.
Вероятно съм пропуснал някои предимства и недостатъци, не се колебайте да коментирате.
