Start

Unternehmen

Buch-Katalog

Seminare

Leserservice

Comelio-Blog

Datenbanken SQL MS SQL Server Oracle Trigger Module Pakete SQLX SysXMLGen XDB: Sichten XDB: XML Schema XDB: XSLT XDB: XMLType XDB: Konzepte XDB: PL/SQL XML-Speicheransätze SQLJ PHP UML C#.NET XML Schema XSLT

Übersicht

Alle Seminare Info-Broschüre Anmeldeformular Hotels & Anfahrt AGB

Comelio GmbH
Rellinghauser Straße 10
D-45128 Essen
Deutschland
Fon: 0201-437517-0
Fax: 0201-437517-10
info@comelio.com

Comelio GmbH
Goethestraße 34
D-13086 Berlin
Deutschland
info@comelio.com

Comelio GmbH (Ecos)
Glockengießerwall 17
D-20095 Hamburg
Deutschland
info@comelio.com

Comelio GmbH (Ecos)
Mainzer Landstraße 27-31
D-60329 Frankfurt
Deutschland
info@comelio.com

Comelio GmbH (Ecos)
Stiglmaierplatz/Dachauer Str. 37
D-80335 München
Deutschland
info@comelio.com

Comelio GmbH (Ecos)
Liebknechtstr. 33
D-70565 Stuttgart
Deutschland
info@comelio.com

Comelio GmbH
Nevinghoff 16
D-48147 Münster
Deutschland

Comelio GmbH
Friedrich - List - Platz 1
D-04103 Leipzig
Deutschland

Comelio GmbH
St. Johanner Strasse 41-43
D-66111 Saarbrücken
Deutschland

Comelio GmbH
Kaiser-Wilhem-Ring 27–29
D-50672 Köln
Deutschland

Comelio GmbH
Münsterstraße 248
D-40470 Düsseldorf
Deutschland

Comelio GmbH
Fürther Strasse
D-90429 Nürnberg
Deutschland

Comelio GmbH

Bremen
Deutschland

Comelio-Blog > Oracle > SQLJ

Java und Oracle mit SQLJ

Bei der Anwendungsentwicklung mit Oracle udn Java existiert neben der Arbeit mit JDBC noch eine weitere Technologie, welche in Form einer Skriptsprache Interaktion mit der Datenbank ermöglich. SQLJ soll in diesem Artikel mit einigen Beispielen auf Syntaxebene und durch entsprechenden Randbemerkungen auch konzeptionell vorgestellt werden.

Kontakt Anrede* Herr Frau Vorname* Nachname* Firma E-Mail* Tel-Nr. Bereich* Comelio-Blog > Oracle > SQLJ Freitext

Oracle und Java: SQLJ

SQLJ ist eine Erweiterung von Java durch eine eingebettete Skriptsprache, die dem Programmierer die Arbeit mit SQL-Anweisungen so komfortabel wie möglich machen soll. Für die Auswertung von Abfrageergebnissen und für das Her-stellen von Datenbankverbindungen gibt es verschiedene SQLJ-Anweisungen, die zum Ziel haben, diese Vorgänge leichter und übersichtlicher steuern zu können, als das mit den entsprechenden JDBC-Aufrufen der Fall ist. SQLJ ist inzwischen ein etablierter Standard, der von bekannten Trendsettern der IT-Branche wie Oracle, IBM, Sun und Sybase getragen wird.

Vom Prinzip her werden die eingebetteten SQLJ-Anweisungen durch einen Präprozessor analysiert und in einen normalen Java-Quelltext umgewandelt, in der Regel in die entsprechenden JDBC-Aufrufe. Dieser Quelltext kann dann anschließend mit dem Java-Compiler javac in Bytecode übersetzt werden.

Die SQLJ-Spezifikation ist inzwischen mehrfach implementiert worden, und es gibt bereits herstellerspezifische Erweiterungen. Im folgenden Artikel behandeln wir Standard-SQLJ. Wenn wir zwischendurch wir auf spezielle Features der SQLJ-Implementierung von Oracle eingehen, wird das im Text explizit erwähnt.

Warum SQLJ?

SQLJ vereinfacht das Programmieren mit SQL. Es unterstützt den Programmierer durch einfache sprachliche Konstrukte beim Einbinden von statischen und – in bestimmtem Umfang – dynamischen SQL-Anweisungen in ein Java-Programm. Dabei ermöglicht SQLJ von der Idee her einen übersichtlichen, unkomplizierten und anpassungsfähigen Code.

Da die in SQLJ verfassten Teile eines Programms durch die SQLJ-Implementierung erst bei der Kompilierung in Java-Quelltext umgewandelt werden, können Hersteller transparent Optimierungen realisieren und eigene Programmierschnittstellen nutzen. Statische SQL-Anweisungen können bei-spielweise bereits zum Zeitpunkt der Syntaxüberprüfung von der Datenbank vorkompiliert werden, und bestimmte datenbankspezifische Erweiterungen können genutzt werden.

Ein weiterer Vorteil besteht in der Möglichkeit, SQL-Anweisungen und die Datenbankverbindung bereits während des Kompilierens zu überprüfen und dort eventuelle Fehler zu finden – und nicht erst zur Laufzeit, wie es bei JDBC-Aufrufen passiert.

Ein kleiner Wermutstropfen ist die Tatsache, dass vor dem eigentlichen Kompi-lieren mit dem Java-Compiler javac zunächst die SQLJ-Implementierung über den Quelltext laufen muss. Das führt in den meisten Fällen zu längeren Kompilierzeiten als bei nativem Java-Quelltext.

Auch die Tatsache, dass im Moment wenige Entwicklungsumgebungen die Mischung von Java und SQLJ unterstützen, macht die Entwicklung mit SQLJ etwas umständlicher. Eventuell müssen Sie die Entwicklungsumgebung wech-seln, einen Weg über die Einstellungen Ihrer aktuellen Umgebung finden oder den Umweg über die Konsole oder ein Kompilierungsskript nehmen.

Wie funktioniert SQLJ?

Eine SQLJ-Anweisung wird im Quelltext mit einer Raute # und dem Schlüsselwort sql eingeleitet, also mit #sql. Am Ende einer SQLJ-Anweisung steht ein Semikolon. Diese eine oder mehrere Zeilen umfassenden SQLJ-Blöcke werden von dem Präprozessor, dem SQLJ-Translator, in gültigen Java-Quelltext umgewandelt. Dieser durch den Präprozessor generierte Quelltext wird dann normal mit javac in ausführbaren Java-Bytecode kompiliert.

Da SQLJ unabhängig von JDBC ist, besteht, wie gesagt, für Hersteller die Möglichkeit, bei der Interpretation der SQLJ-Anweisungen eigene Schnittstellen zu nutzen oder Optimierungsmöglichkeiten auszuschöpfen. Die von Oracles SQLJ-Implementierung generierten Quelltexte nutzen beispielsweise direkt die Klassen aus der unter dem JDBC-Treiber liegenden Implementierung. Die durch den SQLJ-Translator generierten Java-Quelltexte werden übrigens vor dem Kompilieren gespeichert.

SQLJ vs. JDBC

Die Vorteile von SQLJ sieht man am besten im direkten Vergleich mit der Alternative, JDBC. Daher haben wir zwei Quelltextauszüge mit der gleichen Funktionalität einmal mit und einmal ohne SQLJ dargestellt. Beide Quelltexte lesen aus der Tabelle DOZENT der Kursdatenbank den Vor- und Nachnamen in einem Datensatz aus. Im ersten Quelltext sehen Sie den klassischen Weg über die JDBC-Schnittstelle. Anschließend ist die gleiche Operation mit SQLJ dargestellt:

Zunächst also der Weg über die JDBC-Schnittstelle:

      String vorname=null, nachname=null;
int dnr=2;

String query =
    "SELECT D_NACHNAME, D_VORNAME " +
    "FROM DOZENT " +
    "WHERE D_NR=" + dnr;

Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery(query);
if (rs.next()) {
    vorname = rs.getString("D_VORNAME");
    nachname = rs.getString("D_NACHNAME");
}

    

Wenn Sie sich den obigen Quelltext ansehen, fallen Ihnen bestimmt folgende, etwas umständliche Sprachkonstrukte auf, die dem Programmierer von der JDBC-Schnittstelle auferlegt werden, und zwar in analoger Weise für jede einzelne SQL-Anweisung:

• Um eine SQL-Anweisung auszuführen und das Ergebnis auszuwerten, holt man sich jedes Mal über die Methoden createStatement und executeQuery Referenzen auf Objekte vom Typ Statement bzw. ResultSet.
• Da ein ResultSet immer eine Reihe von Datensätzen kapseln könnte, muss man auch bei SQL-Anweisungen, die nur ein einzelnes Ergebnis zurückliefern, dennoch die Methode next und die entsprechende Accessor-Methode aufrufen.
• Obwohl der gewünschte Typ durch die Typendeklaration der Variablen vorname und nachname implizit bereits vorgegeben ist, nämlich java.lang.String, muss man als Programmierer explizit die richtige Methode von ResultSet aufrufen, um einen String zu erhalten.

Und nun der gleiche Vorgang mit SQLJ. Beachten Sie das Konstrukt mit dem einleitenden „#sql“. Dieses leitet den SQLJ-Block ein. Betrachten Sie auch die Kommunikation zwischen dem SQLJ-Block und dem restlichen Quelltext über die so genannten Hostvariablen, also über die Bezeichner im SQLJ-Block mit dem vorangestellten Doppelpunkt, daher :vorname, :nachname und :dnr. Wir gehen später im Detail auf die genaue Anwendung und Syntax der Anweisungen ein; zunächst also der Sprung ins kalte Wasser:

      String vorname=null, nachname=null;
int dnr=2;

#sql {
    SELECT D_VORNAME, D_NACHNAME
      INTO :vorname, :nachname
      FROM DOZENT
      WHERE D_NR=:dnr
};

    

Wenn man Kriterien wie Übersichtlichkeit und Codeumfang auf die beiden Quelltexte anwendet, so liegt unseres Erachtens ganz klar der SQLJ-Quelltext vorne. Was meinen Sie?

SQLJ und JDBC schließen sich dabei nicht gegenseitig aus. So können Sie mit den Hostvariablen innerhalb eines SQLJ-Blocks beispielsweise nicht die SQL-Anweisung selbst modifizieren. Gerade für solche dynamischen SQL-Anweisungen, also SQL-Anweisungen, die komplett durch einen externen Prozess übergeben werden, werden Sie parallel zu den SQLJ-Blöcken auch normale JDBC-Aufrufe programmieren. In gewissem Umfang können Sie dabei bei den JDBC-Aufrufen Ressourcen der SQLJ-Umgebung nutzen und zwischen beiden Umgebungen Daten austauschen.