Verwendung von Prozeduren

Es gibt eine Reihe von Vorteilen für die Verwendung von Prozeduren, die alle darauf basieren, dass die Verwendung von Prozeduren SQL-Anweisungen von der Anwendung in die Datenquelle verschiebt. Was in der Anwendung übrig bleibt, ist ein interoperabler Prozeduraufruf. Folgende Vorteile gibt es:

• Leistungsprozeduren sind in der Regel die schnellste Methode zum Ausführen von SQL-Anweisungen. Wie die vorbereitete Ausführung wird die Anweisung in zwei separaten Schritten kompiliert und ausgeführt. Im Gegensatz zur vorbereiteten Ausführung werden Prozeduren nur zur Laufzeit ausgeführt. Sie werden zu einem anderen Zeitpunkt kompiliert.

• Geschäftsregeln Eine Geschäftsregel ist eine Regel über die Art und Weise, in der ein Unternehmen geschäftet. So kann beispielsweise nur jemand mit dem Titel "Vertriebsmitarbeiter" neue Verkaufsaufträge hinzufügen. Durch das Platzieren dieser Regeln in Prozeduren können einzelne Unternehmen vertikale Anwendungen anpassen, indem die von der Anwendung aufgerufenen Prozeduren umgeschrieben werden, ohne den Anwendungscode ändern zu müssen. Beispielsweise kann eine Auftragseintragsanwendung die Prozedur InsertOrder mit einer festen Anzahl von Parametern aufrufen. Genau wie InsertOrder implementiert wird, kann von Unternehmen zu Unternehmen variieren.

• Die Ersetzungsfähigkeit hängt eng mit der Platzierung von Geschäftsregeln in Verfahren zusammen, da Verfahren ersetzt werden können, ohne die Anwendung neu zu kompilieren. Wenn sich eine Geschäftsregel ändert, nachdem ein Unternehmen eine Anwendung gekauft und installiert hat, kann das Unternehmen das Verfahren ändern, das diese Regel enthält. Aus Der Sicht der Anwendung hat sich nichts geändert; es ruft immer noch eine bestimmte Prozedur auf, um eine bestimmte Aufgabe auszuführen.

• DBMS-spezifische SQL-Prozeduren bieten eine Möglichkeit für Anwendungen, DBMS-spezifische SQL auszunutzen und weiterhin Standard interoperablen. Eine Prozedur für ein DBMS, das Steuerungs-of-Flow-Anweisungen in SQL unterstützt, kann beispielsweise Fehler abfangen und wiederherstellen, während eine Prozedur für ein DBMS, das keine Steuerungs-of-Flow-Anweisungen unterstützt, einfach einen Fehler zurückgibt.

• Prozeduren überleben Transaktionen Bei einigen Datenquellen werden die Zugriffspläne für alle vorbereiteten Anweisungen für eine Verbindung gelöscht, wenn eine Transaktion zugesichert oder zurückgesetzt wird. Durch das Platzieren von SQL-Anweisungen in Prozeduren, die dauerhaft in der Datenquelle gespeichert sind, überleben die Anweisungen die Transaktion. Ob die Verfahren in einem vorbereiteten, teilweise vorbereiteten oder unvorbereiteten Zustand bestehen, ist DBMS-spezifisch.

• Separate Entwicklungsverfahren können separat von der restlichen Anwendung entwickelt werden. In großen Unternehmen könnte dies eine Möglichkeit bieten, die Fähigkeiten hochspezialisierter Programmierer weiter auszunutzen. Mit anderen Worten, Anwendungsprogrammierer können Benutzeroberflächencode und Datenbankprogrammierer Prozeduren schreiben.

Verfahren werden in der Regel von vertikalen und benutzerdefinierten Anwendungen verwendet. Diese Anwendungen führen in der Regel feste Aufgaben aus, und es ist möglich, Prozeduraufrufe mit harter Code in ihnen auszuführen. Beispielsweise kann eine Auftragseintragsanwendung die Prozeduren InsertOrder, DeleteOrder, UpdateOrder und GetOrders aufrufen.

Es gibt wenig Grund, Prozeduren von generischen Anwendungen aufzurufen. Prozeduren werden in der Regel so geschrieben, dass eine Aufgabe im Kontext einer bestimmten Anwendung ausgeführt wird und daher keine generischen Anwendungen verwendet werden. Beispielsweise hat eine Kalkulationstabelle keinen Grund, die InsertOrder-Prozedur nur Erwähnung ed aufzurufen. Darüber hinaus sollten generische Anwendungen keine Prozeduren zur Laufzeit erstellen, um eine schnellere Ausführung von Erklärungen zu ermöglichen; Dies ist nicht nur langsamer als die vorbereitete oder direkte Ausführung, es erfordert auch DBMS-spezifische SQL-Anweisungen.

Eine Ausnahme hierfür ist Anwendungsentwicklungsumgebungen, die häufig eine Möglichkeit zum Erstellen von SQL-Anweisungen bieten, die Prozeduren ausführen und programmierern möglicherweise eine Möglichkeit zum Testen von Prozeduren bieten. Solche Umgebungen rufen SQLProcedures auf, um verfügbare Prozeduren und SQLProcedureColumns auflisten, um die Eingabe-, Eingabe-/Ausgabe- und Ausgabeparameter, den Rückgabewert der Prozedur und die Spalten aller resultsets auflisten, die von einer Prozedur erstellt wurden. Diese Verfahren müssen jedoch vorab für jede Datenquelle entwickelt werden; Dies erfordert DBMS-spezifische SQL-Anweisungen.

Es gibt drei wesentliche Nachteile bei der Verwendung von Verfahren. Zunächst müssen Prozeduren für jedes DBMS geschrieben und kompiliert werden, mit dem die Anwendung ausgeführt werden soll. Dies ist zwar kein Problem für benutzerdefinierte Anwendungen, kann aber die Entwicklung und Standard Zeit für vertikale Anwendungen, die für die Ausführung mit einer Reihe von DBMSs entwickelt wurden, erheblich erhöhen.

Der zweite Nachteil ist, dass viele DBMSs keine Verfahren unterstützen. Dies ist wahrscheinlich ein Problem für vertikale Anwendungen, die für die Ausführung mit einer Reihe von DBMSs entwickelt wurden. Um festzustellen, ob Prozeduren unterstützt werden, ruft eine Anwendung SQLGetInfo mit der Option SQL_PROCEDURES auf.

Der dritte Nachteil, der insbesondere für Anwendungsentwicklungsumgebungen gilt, besteht darin, dass ODBC keine Standardgrammatik zum Erstellen von Prozeduren definiert. Das heißt, anwendungen können Prozeduren zwar interoperabel aufrufen, aber sie können sie nicht interoperabel erstellen.