To, czy korzystać z procedur przechowywanych, czy nie, to bardziej dyskusja religijna lub polityczna przy barze niż nie.
Należy jasno zdefiniować warstwy aplikacji i nie przekraczać tych granic. Procedury składowane mają kilka zalet i wad w porównaniu z wykonywaniem zapytań poza bazą danych.
Zaleta 1:Procedury składowane są modułowe. To dobra rzecz z punktu widzenia konserwacji. Gdy w Twojej aplikacji pojawią się problemy z zapytaniami, prawdopodobnie zgodzisz się, że znacznie łatwiej jest rozwiązywać problemy z procedurą składowaną niż z osadzonym zapytaniem ukrytym w wielu wierszach kodu GUI.
Zaleta 2:Procedury składowane można dostrajać. Dzięki procedurom obsługującym bazę danych w interfejsie eliminujesz potrzebę modyfikowania kodu źródłowego GUI w celu poprawy wydajności zapytania. W procedurach składowanych można wprowadzać zmiany — w zakresie metod łączenia, różniących się tabel itp. — które są niewidoczne dla interfejsu użytkownika.
Zaleta 3:Procedury składowane stanowią abstrakcję lub oddzielają funkcje po stronie serwera od funkcji po stronie klienta. O wiele łatwiej jest zakodować aplikację GUI, aby wywołać procedurę, niż budować zapytanie za pomocą kodu GUI.
Zaleta 4:Procedury składowane są zwykle pisane przez deweloperów/administratorów baz danych. Osoby pełniące te role mają zwykle większe doświadczenie w pisaniu wydajnych zapytań i instrukcji SQL. Pozwala to programistom aplikacji GUI wykorzystać swoje umiejętności na funkcjonalnych i graficznych elementach prezentacji aplikacji. Jeśli Twoi ludzie wykonują zadania, do których są najlepiej przystosowani, ostatecznie uzyskasz lepszą ogólną aplikację.
Mając to wszystko na uwadze, istnieje kilka wad.
Wada 1:Aplikacje, które obejmują rozbudowaną logikę biznesową i przetwarzanie, mogą nadmiernie obciążać serwer, jeśli logika zostałaby zaimplementowana w całości w procedurach składowanych. Przykłady tego typu przetwarzania obejmują transfery danych, przechodzenie danych, transformacje danych i intensywne operacje obliczeniowe. Powinieneś przenieść ten typ przetwarzania do procesów biznesowych lub komponentów logiki dostępu do danych, które są bardziej skalowalnym zasobem niż serwer bazy danych.
Wada 2:Nie umieszczaj całej logiki biznesowej w procedurach składowanych. Utrzymanie i sprawność Twojej aplikacji staje się problemem, gdy musisz zmodyfikować logikę biznesową w języku Sp. Na przykład aplikacje niezależnych dostawców oprogramowania, które obsługują wiele RDBMS, nie powinny wymagać utrzymywania oddzielnych procedur składowanych dla każdego systemu.
Wada 3:Pisanie i utrzymywanie procedur składowanych to najczęściej wyspecjalizowany zestaw umiejętności, który nie wszyscy programiści posiadają. Taka sytuacja może powodować wąskie gardła w harmonogramie rozwoju projektu.
Prawdopodobnie przegapiłem kilka zalet i wad, zachęcam do komentowania.
