Jul 032011
 

Stored Procedures – ja oder nein?

PL/SQL ist die Sprache für Stored Procedures in Oracles Datenbank. Sie hat Ähnlichkeiten mit Ada 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):

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.

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)