Stored Procedures – ja oder nein?
[wikipop]PL/SQL[/wikipop] ist die Sprache für [wikipop]Stored Procedures[/wikipop] in [wikipop search=“Oracle Database“]Oracles Datenbank[/wikipop]. Sie hat Ähnlichkeiten mit [wikipop search=“Ada (programming language)“]Ada[/wikipop] und ihr primärer Vorteil gegenüber anderen Sprachen ist die nahtlose Intergration von Oracles SQL-Dialekt in die Sprache:
function get_count( key_mask in varchar2 default null ) return integer is result integer; begin select count(1) into result from my_table where identifier like NVL(key_mask, '%'); return result; end;
Diskussionen zum Für und Wider von Stored Procedures vor allem im Zusammenhang mit Application Server-Architekturen finden sich reichlich im Netz (und man kann sicher mit etwas Polemik jederzeit seinen eigenen Thread in diversen Foren, Wikis und Blogs lostreten):
- Von syntaktischen zu architektonischen Aspekten inkl. weiterführender Links (letzter Eintrag 02.09.2008)
- Sachlich und recht neutral mit weiteren Links (von Januar 2006)
- Argumente auf stackoverflow (September 2008 mit einem immerhin unterhaltsamen Troll-Post von 2010)
Das Fazit für mich ist, dass man sich bei der Entscheidung für oder gegen Stored Procedures im allgemeinen und PL/SQL im besonderen mit verschiedenen Fragen auseinandersetzen muss wie:
- Ist ein relationales Datenmodell der Kern meiner Anwendung(en) – und wird evtl. gar „nach außen“ dokumentiert – oder nur ein internes Detail zur persistenten Ablage der Anwendungsdaten?
- Ist Datenbankunabhängigkeit wirklich ein Hauptziel meiner Entwicklung? Habe ich die entsprechenden Installationen, Administratoren, Verteilungs- und Test-Mechanismen, um meine Software jederzeit gegen wenigstens zwei unterschiedliche Datenbank-Produkte laufen lassen zu können? Oder ist im Gegenteil ein Datenbanksystem schon gesetzt, kann ich also auch seine besonderen Eigenschaften, Schnittstellen, Tools etc. ausnutzen?
- Gibt es ein vorgegebenes Umfeld beim Kunden, in dem meine Anwendung laufen soll? Wenn eine JEE-Architekur mit Application Server nach Lehrbuch bedient werden muss, klingt das nicht nach Stored Procedures.
- Welche Sprachen, Techniken und Frameworks beherrscht mein Entwickler-Team?
- Wie mächtig ist die Stored Procedures-Sprache meiner Datenbank? Dazu gehören die Fragen: Gibt es mehrere Sprachen zur Auswahl und lassen sie sich kombinieren? Ist eine General Purpose Language wie Java, .NET oder C++ dabei? Wie sieht es mit dynamischen Features aus, um z. B. Datenbank-Objekte zur Laufzeit anlegen, modifizieren bzw. löschen zu können? Gibt es Schnittstellen zur Analyse und Verwaltung des gesamten Datenbanksystems? Gibt es Netzwerk-Schnittstellen, um z. B. Mails versenden, HTTP-Anfragen stellen, Messaging-Systeme bedienen oder TCP/UDP-Verbindungen aufbauen zu können?
- Wie lange wird das Datenmodell in der Datenbank voraussichtlich leben; 2, 5, 10 oder 20 Jahre? Ist auch die Präsentationsschicht – also Nutzeroberfläche, Webserver – für diese Laufzeit ausgelegt?
- Sollen verschiedene Anwendungen von unterschiedlichen Umgebungen aus auf die Daten zugreifen, also z. B. JEE-gestützte Anwendungen, „normale“ Windows-Clients, Batchverarbeitungen, Webservice-Anschlüsse …? Sind Art, Anzahl und Plattformen der Anwendungen überhaupt von vornherein bekannt?
Da es hier um PL/SQL gehen soll, gehe ich mal einfach davon aus, dass diese und andere Fragen zugunsten der Oracle-Datenbank und PL/SQL beantwortet wurden, und kann mich nun unbeschwert von philosophischen Aspekten der Frage zuwenden, wie man effektiv in PL/SQL entwickeln kann.