22_8335_601-RDBM-Schnittstellen in der Praxis

In diesem Abschnitten wollen wir uns mit den
wichtigsten Schnittstellen beschäftigen, die bei
der Entwicklung einer Datenbank-Software in
der Praxis eine Rolle spielen.
1
In diesem Abschnitt wollen wir analysieren,
was passiert, wenn wir aus einer
Anwendung heraus auf Datenbanken
zugreifen.
Im Detail hängt dies von verschiedenen
Faktoren ab:
• In welcher Programmiersprache ist die
Anwendung erstellt
• Welche Schnittstelle verwendet die
Anwendung, um auf die Datenbank zu
zugreifen
Um das Wesentliche nicht aus dem Blick zu
verlieren, wollen wir uns hier nur die
2
wichtigsten Programmier-Paradigmen und
Konzepte ansehen, und uns klar machen,
welche Probleme in der Praxis auftreten können.
Zu diesem Zweck, schauen wir uns einige DMLSQL Abweisungen. Im einzelnen sind dies
• INSERT
• UPDATE
• DELETE
• SELECT
In dieser Abbildung ist zu sehen, was passiert, wenn man aus einer Anwendung heraus einen Datensatz mi
Wurde an die Datenbank die INSERT Anweisung übergeben, so erhalten wir als Ergebnis entweder:
• Eine OK Meldung, sofern der INSERT erfolgreich war
• Eine Fehlermeldung , sofern ein Problem aufgetreten ist.
Das Verhalten ist wie bei einem SQL Interpreter. Hier ist nur der Unterschied, dass die Meldungen nicht a
In dieser Abbildung ist zu sehen, was passiert, wenn man aus einer Anwendung heraus einen Datensatz mi
Wurde an die Datenbank die UPDATE oder DELETE Anweisung übergeben, so erhalten wir als Ergebnis
• Eine OK Meldung, sofern der INSERT erfolgreich war
• Eine Fehlermeldung , sofern ein Problem aufgetreten ist.
Das Verhalten ist wie bei einem SQL Interpreter. Hier ist nur der Unterschied, dass die Meldungen nicht a
Also genau das gleiche Paradigma wie bei der Ausführung einer SQL INSERT Anweisung.
In dieser Abbildung wollen wir uns näher ansehen, was nun bei einer SQL-SELECT Anweisung passiert.
Wurde an die Datenbank die SELECT Anweisung übergeben, so erhalten wir als Ergebnis entweder:
• Eine Fehlermeldung , sofern ein Problem aufgetreten ist.
• Eine Ergebnismenge, sofern der SELECT erfolgreich war.
Das Verhalten ist wie bei einem SQL Interpreter. Hier ist nur der Unterschied, dass die Meldungen nicht a
Die Frage hier ist nur:
Was passiert, wenn die Anzahl der Sätze in der Ergebnismenge sehr groß ist?
Wie man sich gut vorstellen kann, sollte es kein Problem sein, einige hundert Datensätze in der Applikatio
Ist die Datenmenge sehr groß ( einige Hunderttausend), kann es Probleme geben, da die Größe des Hau
Wie eine Lösung in der Praxis aussieht, schauen wir uns auf der nächsten Abbildung an.
Bei sehr großen Ergebnismengen, wird an die Applikation nicht die Datenmenge direkt zurückgegeben, so
Die CURSOR kann man als Zeigestock verstehen, der es einer Anwendung ermöglicht, innerhalb der Erge
Ein CURSOR ist also eine Referenz auf eine Ergebnismenge, die auf eine bestimmte Position in der Ergeb
Schauen wir uns hierzu einmal einen solches Szenario genauer an:
1. Im ersten Schritt sendet die Anwendung das SELECT Statement an die Datenbank.
2. Danach führt die Datenbank das SELECT Statement aus und berechnet / bildet die Ergebnismenge.
3. Anschließend gibt die Datenbank ein Cursor-Objekt an die Anwendung zurück.
4. Die Anwendung kann nun über diesen Cursor auf die Ergebnismenge zugreifen.
Siehe auch:
• Microsoft SQL Server; JDBC: https://msdn.microsoft.com/de-de/library/ms378737(v=sql.110).aspx
• ORACLE, PL/SQL http://www.oracle.com/technetwork/issue-archive/2013/13-mar/o23plsql-1906474.
Aus Effizienzgründen unterscheidet man unterschiedliche Cursor-Typen. Diese können von der Anwendu
• Vorwärts-Cursor – Durchlaufen der Ergebnismenge nur in einer Richtung
• Scroll-Fähige Cursor – Erlaubt das Durchlaufen der Ergebnismenge in beide Richtungen
In allen Fällen muss die Applikation den Cursor expliziert schließen. Damit zeigt die Applikation gegenüb