Kiedy należy używać procedur

Istnieje wiele zalet korzystania z procedur, wszystkie w oparciu o fakt, że użycie procedur przenosi instrukcje SQL z aplikacji do źródła danych. To, co pozostało w aplikacji, to interoperacyjne wywołanie procedury. Te zalety obejmują:

• Wydajności Procedury są zwykle najszybszym sposobem wykonywania instrukcji SQL. Podobnie jak w przypadku przygotowanego wykonania instrukcja jest kompilowana i wykonywana w dwóch oddzielnych krokach. W przeciwieństwie do przygotowanego wykonywania poleceń, procedury są wykonywane tylko podczas działania. Są one kompilowane w innym czasie.

• Reguły biznesoweReguła biznesowa to reguła dotycząca sposobu, w jaki firma prowadzi działalność. Na przykład tylko osoba z tytułem Sales Person może mieć możliwość dodania nowych zamówień sprzedaży. Umieszczenie tych reguł w procedurach umożliwia poszczególnym firmom dostosowywanie aplikacji pionowych przez ponowne zapisywanie procedur wywoływanych przez aplikację bez konieczności modyfikowania kodu aplikacji. Na przykład aplikacja wpisu zamówienia może wywołać procedurę InsertOrder ze stałą liczbą parametrów; dokładnie w jaki sposób implementacja insertorder może się różnić w zależności od firmy.

• Możliwość zamiany Ściśle związane z umieszczaniem reguł biznesowych w procedurach jest fakt, że procedury można zastąpić bez ponownego komplikowania aplikacji. Jeśli reguła biznesowa zmieni się po zakupie i zainstalowaniu aplikacji przez firmę, firma może zmienić procedurę zawierającą daną regułę. Z punktu widzenia aplikacji nic się nie zmieniło; nadal wywołuje określoną procedurę w celu wykonania określonego zadania.

• SQL specyficzny dla systemu DBMS Procedury umożliwiają aplikacjom wykorzystanie języka SQL specyficznego dla systemu DBMS i nadal pozostają w stanie współdziałania. Na przykład procedura w systemie DBMS, która obsługuje instrukcje sterowania przepływem w języku SQL, może wychwycić i odzyskać dane po błędach, podczas gdy procedura w systemie DBMS, która nie obsługuje instrukcji control-of-flow, może po prostu zwrócić błąd.

• Procedury przetrwają transakcje W niektórych źródłach danych plany dostępu dla wszystkich przygotowanych instrukcji połączenia są usuwane po zatwierdzeniu lub wycofaniu transakcji. Umieszczając instrukcje SQL w procedurach, które są trwale przechowywane w źródle danych, instrukcje przetrwają transakcję. To, czy procedury przetrwają w przygotowanym, częściowo przygotowanym, czy nieprzygotowanym stanie, jest specyficzne dla systemu DBMS.

• Oddzielne programowanie Procedury można opracowywać oddzielnie od pozostałej części aplikacji. W dużych korporacjach może to stanowić sposób na dalsze wykorzystanie umiejętności wysoko wyspecjalizowanych programistów. Innymi słowy, programiści aplikacji mogą pisać kod interfejsu użytkownika, a programiści baz danych mogą pisać procedury.

Procedury są zwykle używane przez aplikacje pionowe i niestandardowe. Te aplikacje zwykle wykonują stałe zadania, a możliwe jest sztywne wywoływanie procedur w nich. Na przykład aplikacja wpisu zamówienia może wywoływać procedury InsertOrder, DeleteOrder, UpdateOrder i GetOrders.

Nie ma powodu do wywoływania procedur z aplikacji ogólnych. Procedury są zwykle zapisywane w celu wykonania zadania w kontekście określonej aplikacji i nie mają zastosowania do ogólnych aplikacji. Na przykład arkusz kalkulacyjny nie ma powodu, aby wywołać właśnie wymienioną procedurę InsertOrder . Ponadto ogólne aplikacje nie powinny tworzyć procedur w czasie wykonywania w nadziei na szybsze wykonywanie instrukcji; Nie tylko może to być wolniejsze niż przygotowanie lub bezpośrednie wykonanie, ale także wymaga instrukcji SQL specyficznych dla systemu DBMS.

Wyjątkiem od tego jest środowisko deweloperskie aplikacji, które często zapewniają programistom możliwość tworzenia instrukcji SQL, które wykonują procedury i mogą zapewnić programistom możliwość testowania procedur. Takie środowiska wywołają metodę SQLProcedures , aby wyświetlić listę dostępnych procedur i metod SQLProcedureColumns w celu wyświetlenia listy parametrów wejściowych, wejściowych/wyjściowych i wyjściowych, wartości zwracanej procedury oraz kolumn wszystkich zestawów wyników utworzonych przez procedurę. Jednak takie procedury należy opracowywać wcześniej w każdym źródle danych; Wymaga to instrukcji SQL specyficznych dla systemu DBMS.

Istnieją trzy główne wady korzystania z procedur. Po pierwsze, procedury muszą być napisane i skompilowane dla każdego systemu DBMS, za pomocą którego aplikacja ma być uruchamiana. Chociaż nie jest to problem w przypadku aplikacji niestandardowych, może znacznie zwiększyć czas programowania i konserwacji aplikacji pionowych przeznaczonych do uruchamiania z wieloma systemami DBMS.

Drugą wadą jest to, że wiele zestawów DBMS nie obsługuje procedur. Najprawdopodobniej jest to problem z aplikacjami pionowymi przeznaczonymi do uruchamiania z wieloma systemami DBMS. Aby określić, czy procedury są obsługiwane, aplikacja wywołuje element SQLGetInfo z opcją SQL_PROCEDURES.

Trzecia wada, która jest szczególnie stosowana w środowiskach deweloperskich aplikacji, jest to, że ODBC nie definiuje standardowej gramatyki do tworzenia procedur. Oznacza to, że chociaż aplikacje mogą wywoływać procedury współpracująco, nie mogą ich tworzyć w sposób interoperacyjny.