FOR UPDATE tut nicht das, was der Name vermuten lässt.Der einzige Effekt besteht derzeit darin, den Prefetch-Puffer zu deaktivieren.

Die Unterklausel OF tut überhaupt nichts.

Begrenzte pessimistische Sperrung

DSQL, PSQL

WITH LOCK bietet eine begrenzte explizite pessimistische Sperrfunktion für die vorsichtige Verwendung unter Bedingungen, in denen das betroffene Rowset:

Wenn die Klausel WITH LOCK erfolgreich ist, sichert sie eine Sperre für die ausgewählten Zeilen und verhindert, dass andere Transaktionen Schreibzugriff auf eine dieser Zeilen oder ihre abhängigen Zeilen erhalten, bis Ihre Transaktion beendet ist.

WITH LOCK kann nur mit einer SELECT-Anweisung der obersten Ebene für eine einzelne Tabelle verwendet werden.Es ist nicht verfügbar:

Da die Engine wiederum berücksichtigt, dass jeder Datensatz unter eine explizite Sperranweisung fällt, gibt sie entweder die aktuellste festgeschriebene Datensatzversion zurück, unabhängig vom Datenbankstatus, als die Anweisung übergeben wurde, oder eine Ausnahme.

Das Warteverhalten und die Konfliktmeldung hängen von den im TPB-Block angegebenen Transaktionsparametern ab:

Wenn die Unterklausel FOR UPDATE vor der Unterklausel WITH LOCK steht, werden gepufferte Abrufe unterdrückt.Somit wird die Sperre nacheinander auf jede Zeile angewendet, sobald sie abgerufen wird.Es wird dann möglich, dass eine Sperre, die auf Anforderung erfolgreich erschien, trotzdem nachträglich fehlschlägt, wenn versucht wird, eine Zeile abzurufen, die zwischenzeitlich durch eine andere Transaktion gesperrt wurde.

FOR UPDATE [OF]

Wenn eine UPDATE-Anweisung versucht, auf einen Datensatz zuzugreifen, der durch eine andere Transaktion gesperrt ist, löst sie je nach TPB-Modus entweder eine Aktualisierungskonfliktausnahme aus oder wartet auf den Abschluss der Sperrtransaktion.Das Engine-Verhalten ist hier dasselbe, als ob dieser Datensatz bereits durch die Sperrtransaktion geändert worden wäre.

Bei Konflikten mit pessimistischen Sperren werden keine speziellen gdscodes zurückgegeben.

Die Engine garantiert, dass alle von einer expliziten Sperranweisung zurückgegebenen Datensätze tatsächlich gesperrt sind und ob die in der WHERE-Klausel angegebenen Suchbedingungen erfüllen, solange die Suchbedingungen nicht von anderen Tabellen abhängen, über Joins, Unterabfragen usw.Es garantiert auch, dass Zeilen, die die Suchbedingungen nicht erfüllen, nicht durch die Anweisung gesperrt werden.Es kann nicht garantieren, dass es keine Zeilen gibt, die zwar die Suchbedingungen erfüllen, aber nicht gesperrt sind.

Die Engine sperrt Zeilen zum Abrufzeitpunkt.Dies hat wichtige Konsequenzen, wenn Sie mehrere Zeilen gleichzeitig sperren.Viele Zugriffsmethoden für Firebird-Datenbanken holen standardmäßig die Ausgabe in Paketen von einigen hundert Zeilen (“buffered fetches”).Die meisten Datenzugriffskomponenten können Ihnen die im zuletzt abgerufenen Paket enthaltenen Zeilen nicht liefern, wenn ein Fehler aufgetreten ist.

SELECT-Ausgabe an Variablen übergeben

PSQL

In PSQL wird die INTO-Klausel ganz am Ende der SELECT-Anweisung platziert.

In PSQL-Code (Trigger, Stored Procedures und ausführbare Blöcke) können die Ergebnisse einer SELECT-Anweisung zeilenweise in lokale Variablen geladen werden.Dies ist oft die einzige Möglichkeit, überhaupt etwas mit den zurückgegebenen Werten zu tun, es sei denn, es wird ein expliziter oder impliziter Cursorname angegeben.Anzahl, Reihenfolge und Typen der Variablen müssen mit den Spalten in der Ausgabezeile übereinstimmen.

Eine “plain” SELECT-Anweisung kann in PSQL nur verwendet werden, wenn sie höchstens eine Zeile zurückgibt, d.h. wenn es sich um eine singleton select handelt.Für mehrzeilige Selects bietet PSQL das Schleifenkonstrukt FOR SELECT, das später im PSQL-Kapitel besprochen wird.PSQL unterstützt auch die DECLARE CURSOR-Anweisung, die einen benannten Cursor an eine SELECT-Anweisung bindet.Der Cursor kann dann verwendet werden, um die Ergebnismenge zu durchlaufen.

DSQL, PSQL

Ein allgemeiner Tabellenausdruck oder CTE kann als virtuelle Tabelle oder Ansicht beschrieben werden, die in einer Präambel einer Hauptabfrage definiert ist und nach der Ausführung der Hauptabfrage den Gültigkeitsbereich verlässt.Die Hauptabfrage kann auf alle CTEs verweisen, die in der Präambel definiert sind, als wären es reguläre Tabellen oder Ansichten.CTEs können rekursiv, d.h. selbstreferenzierend, aber nicht verschachtelt sein.

Ein rekursiver (selbstreferenzierender) CTE ist eine UNION, die mindestens ein nicht-rekursives Element namens anchor haben muss.Das/die nicht-rekursive(n) Element(e) muss/müssen vor dem/den rekursiven Element(en) platziert werden.Rekursive Elemente sind miteinander und mit ihrem nicht-rekursiven Nachbarn durch UNION ALL-Operatoren verknüpft.Die Vereinigungen zwischen nicht-rekursiven Mitgliedern können von jedem Typ sein.

Rekursive CTEs erfordern, dass das Schlüsselwort RECURSIVE direkt nach WITH vorhanden ist.Jedes rekursive Unionsmitglied darf nur einmal auf sich selbst verweisen, und zwar in einer FROM-Klausel.

Ein großer Vorteil rekursiver CTEs besteht darin, dass sie weit weniger Speicher und CPU-Zyklen benötigen als eine entsprechende rekursive gespeicherte Prozedur.

Das Ausführungsmuster eines rekursiven CTE sieht wie folgt aus:

Das nächste Beispiel gibt den Stammbaum eines Pferdes zurück.Der Hauptunterschied besteht darin, dass die Rekursion in zwei Zweigen des Stammbaums gleichzeitig auftritt.

Die Spaltenliste enthält einen oder mehrere durch Kommas getrennte Wertausdrücke.Jeder Ausdruck stellt einen Wert für eine Ausgabespalte bereit.Alternativ kann * (“Hole Sternchen” oder “Hole alle”) verwendet werden, um für alle Spalten in einer Relation (d.h. einer Tabelle, View oder auswählbaren Stored Procedure) zu stehen.

Es ist immer gültig, einen Spaltennamen (oder “*”) mit dem Namen oder Alias der Tabelle, Ansicht oder auswählbaren SP, zu der er gehört, zu qualifizieren, gefolgt von einem Punkt (‘.’).Beispiel: Beziehungsname.Spaltenname, Beziehungsname.*, Alias.Spaltenname, Alias.*.Qualifizierend ist erforderlich, wenn der Spaltenname in mehr als einer Relation vorkommt, die an einem Join teilnimmt.Das Qualifizieren von “*” ist immer obligatorisch, wenn es nicht das einzige Element in der Spaltenliste ist.

Der Spaltenliste kann optional eines der Schlüsselwörter DISTINCT oder ALL vorangestellt werden:

Eine COLLATE-Klausel ändert das Aussehen der Spalte als solche nicht.Wenn die angegebene Sortierung jedoch die Groß-/Kleinschreibung oder die Akzentempfindlichkeit der Spalte ändert, kann dies Folgendes beeinflussen:

Ein einfaches SELECT, das nur Spaltennamen verwendet:

Eine Abfrage mit einem Verkettungsausdruck und einem Funktionsaufruf in der Spaltenliste:

Eine Abfrage mit zwei Unterauswahlen:

Die folgende Abfrage bewirkt dasselbe wie die vorherige, indem Joins anstelle von Subselects verwendet werden:

Diese Abfrage verwendet ein CASE-Konstrukt, um den richtigen Titel zu ermitteln, z.B.beim Senden von E-Mails an eine Person:

Abfrage über eine Fensterfunktion.Sortiert Mitarbeiter nach Gehalt.

Abfrage einer auswählbaren gespeicherten Prozedur:

Auswählen aus Spalten einer abgeleiteten Tabelle.Eine abgeleitete Tabelle ist eine SELECT-Anweisung in Klammern, deren Ergebnismenge in einer einschließenden Abfrage verwendet wird, als wäre es eine reguläre Tabelle oder Ansicht.Die abgeleitete Tabelle ist hier fett gedruckt:

Abfrage der Uhrzeit über eine Kontextvariable (CURRENT_TIME):

Für diejenigen, die mit RDB$DATABASE nicht vertraut sind: Dies ist eine Systemtabelle, die in allen Firebird-Datenbanken vorhanden ist und garantiert genau eine Zeile enthält.Obwohl es nicht für diesen Zweck erstellt wurde, ist es unter Firebird-Programmierern zur Standardpraxis geworden, aus dieser Tabelle auszuwählen, wenn Sie “from Nothing” auswählen möchten, dh wenn Sie Daten benötigen, die nicht an eine Tabelle oder Ansicht gebunden sind, kann aber allein aus den Ausdrücken in den Ausgabespalten abgeleitet werden.Ein anderes Beispiel ist:

Schließlich ein Beispiel, in dem Sie einige aussagekräftige Informationen aus RDB$DATABASE selbst auswählen:

Wie Sie vielleicht erraten haben, erhalten Sie dadurch den Standardzeichensatz der Datenbank.

Funktionen, Aggregatfunktionen, Window-Funktionen>, <<fblangref40-contextvars-de,Kontextvariablen, CASE, Unterabfragen

Die FROM-Klausel gibt die Quelle(n) an, aus der die Daten abgerufen werden sollen.In seiner einfachsten Form ist dies nur eine einzelne Tabelle oder Ansicht.Die Quelle kann jedoch auch eine auswählbare gespeicherte Prozedur, eine abgeleitete Tabelle oder ein allgemeiner Tabellenausdruck sein.Mehrere Quellen können mit verschiedenen Arten von Joins kombiniert werden.

Dieser Abschnitt konzentriert sich auf Single-Source-Selects.Joins werden in einem der folgenden Abschnitte behandelt.

Bei der Auswahl aus einer einzelnen Tabelle oder Ansicht erfordert die FROM-Klausel nur den Namen.Ein Alias kann nützlich oder sogar notwendig sein, wenn es Unterabfragen gibt, die sich auf die Haupt-select-Anweisung beziehen (wie sie es oft tun — Unterabfragen wie diese werden als korrelierte Unterabfragen bezeichnet).

Eine auswählbare gespeicherte Prozedur ist eine Prozedur, die:

Die Ausgabeparameter einer auswählbaren gespeicherten Prozedur entsprechen den Spalten einer regulären Tabelle.

Die Auswahl aus einer gespeicherten Prozedur ohne Eingabeparameter entspricht der Auswahl aus einer Tabelle oder Ansicht:

Alle erforderlichen Eingabeparameter müssen nach dem Prozedurnamen in Klammern angegeben werden:

Werte für optionale Parameter (dh Parameter, für die Standardwerte definiert wurden) können weggelassen oder bereitgestellt werden.Wenn Sie sie jedoch nur teilweise bereitstellen, müssen sich die weggelassenen Parameter alle am Ende befinden.

Angenommen, die Prozedur visible_stars aus dem vorherigen Beispiel hat zwei optionale Parameter: min_magn (numeric(3,1)) und spectral_class (varchar(12)), sind die folgenden Abfragen gültig:

Dies ist jedoch nicht der Fall, da die Parameterliste ein “hole” enthält:

Ein Alias für eine auswählbare gespeicherte Prozedur wird nach der Parameterliste angegeben:

Wenn Sie auf einen Ausgabeparameter (“column”) verweisen, indem Sie ihn mit dem vollständigen Prozedurnamen qualifizieren, sollte der Prozeduralias weggelassen werden:

Stored Procedures, CREATE PROCEDURE

Eine abgeleitete Tabelle ist eine gültige SELECT-Anweisung in Klammern, optional gefolgt von einem Tabellenalias und/oder Spaltenaliasen.Die Ergebnismenge der Anweisung fungiert als virtuelle Tabelle, die die einschließende Anweisung abfragen kann.

Der von diesem “SELECT FROM (SELECT FROM..)”-Stil der Anweisung zurückgegebene Datensatz ist eine virtuelle Tabelle, die innerhalb der einschließenden Anweisung abgefragt werden kann, als wäre es eine reguläre Tabelle oder Ansicht.

Das Schlüsselwort "LATERAL" kennzeichnet eine Tabelle als eine lateral abgeleitete Tabelle.Lateral abgeleitete Tabellen können auf Tabellen (einschließlich abgeleiteter Tabellen) verweisen, die früher in der FROM-Klausel vorkommen.Weitere Informationen finden Sie unter [fblangref40-dml-select-joins-lateral-de].

Die abgeleitete Tabelle in der folgenden Abfrage gibt die Liste der Tabellennamen in der Datenbank und die Anzahl der Spalten in jeder Tabelle zurück.Eine “Drill-Down”-Abfrage für die abgeleitete Tabelle gibt die Anzahl der Felder und die Anzahl der Tabellen mit jeder Feldanzahl zurück:

Ein triviales Beispiel, das zeigt, wie der Alias einer abgeleiteten Tabelle und die Liste der Spaltenaliase (beide optional) verwendet werden können:

Angenommen, wir haben eine Tabelle COEFFS, die die Koeffizienten einer Reihe von quadratischen Gleichungen enthält, die wir lösen müssen.Es wurde wie folgt definiert:

Abhängig von den Werten von 'a', 'b' und 'c' kann jede Gleichung null, eine oder zwei Lösungen haben.Es ist möglich, diese Lösungen mit einer einstufigen Abfrage der Tabelle COEFFS zu finden, aber der Code sieht ziemlich unordentlich aus und mehrere Werte (wie die Diskriminante) müssen mehrmals pro Zeile berechnet werden.Eine abgeleitete Tabelle kann hier helfen, die Dinge sauber zu halten:

Wenn wir die Koeffizienten neben den Lösungen anzeigen möchten (was möglicherweise keine schlechte Idee ist), können wir die Abfrage wie folgt ändern:

Beachten Sie, dass, während die erste Abfrage eine Spaltenaliasliste für die abgeleitete Tabelle verwendet, die zweite bei Bedarf intern Aliase hinzufügt.Beide Methoden funktionieren, solange jede Spalte garantiert einen Namen hat.

Ein allgemeiner Tabellenausdruck – oder CTE – ist eine komplexere Variante der abgeleiteten Tabelle, aber auch leistungsfähiger.Eine Präambel, die mit dem Schlüsselwort WITH beginnt, definiert eine oder mehrere benannte CTEs, jede mit einer optionalen Spalten-Alias-Liste.Die Hauptabfrage, die der Präambel folgt, kann dann auf diese CTEs zugreifen, als wären es reguläre Tabellen oder Ansichten.Die CTEs verlassen den Gültigkeitsbereich, sobald die Hauptabfrage vollständig ausgeführt wurde.

Eine vollständige Diskussion der CTEs finden Sie im Abschnitt [fblangref40-dml-select-cte-de].

Das Folgende ist eine Umschreibung unseres abgeleiteten Tabellenbeispiels als CTE:

Abgesehen davon, dass die Berechnungen, die zuerst durchgeführt werden müssen, jetzt am Anfang stehen, ist dies keine große Verbesserung gegenüber der abgeleiteten Tabellenversion.Allerdings können wir jetzt auch die doppelte Berechnung von sqrt(D) für jede Zeile eliminieren:

Der Code ist jetzt etwas komplizierter, kann aber effizienter ausgeführt werden (je nachdem, was länger dauert: Ausführen der SQRT-Funktion oder Übergabe der Werte von b, D und denom durch einen zusätzlichen CTE) .Übrigens hätten wir das auch mit abgeleiteten Tabellen machen können, aber das würde eine Verschachtelung erfordern.

[fblangref40-dml-select-cte-de].

Joins kombinieren Daten aus zwei Quellen zu einem einzigen Satz.Dies erfolgt zeilenweise und beinhaltet normalerweise die Überprüfung einer Join-Bedingung, um zu bestimmen, welche Zeilen zusammengeführt und im resultierenden Dataset erscheinen sollen.Es gibt verschiedene Typen (INNER, OUTER) und Klassen (qualifiziert, natürlich usw.) von Joins, jede mit ihrer eigenen Syntax und eigenen Regeln.

Da Joins verkettet werden können, können die an einem Join beteiligten Datasets selbst verbundene Sets sein.

Ein Join kombiniert immer Datenzeilen aus zwei Sätzen (normalerweise als linker Satz und rechter Satz bezeichnet).Standardmäßig gelangen nur Zeilen in die Ergebnismenge, die die Join-Bedingung erfüllen (d. h. die mindestens einer Zeile in der anderen Menge entsprechen, wenn die Join-Bedingung angewendet wird).Dieser Standard-Join-Typ wird als inner join bezeichnet.Angenommen, wir haben die folgenden zwei Tabellen:

Wenn wir diese Tabellen wie folgt verbinden:

dann ist die Ergebnismenge:

Die erste Reihe von A wurde mit der zweiten Reihe von B verbunden, weil sie zusammen die Bedingung “A.id = B.code” erfüllten.Die anderen Zeilen aus den Quelltabellen haben keine Übereinstimmung in der entgegengesetzten Menge und werden daher nicht in den Join aufgenommen.Denken Sie daran, dies ist ein INNER-Join.Wir können diese Tatsache explizit machen, indem wir schreiben:

Da jedoch INNER die Vorgabe ist, wird es normalerweise weggelassen.

Es ist durchaus möglich, dass eine Reihe im linken Satz mit mehreren Reihen im rechten Satz übereinstimmt oder umgekehrt.In diesem Fall sind alle diese Kombinationen enthalten, und wir können Ergebnisse erhalten wie:

Manchmal möchten (oder müssen) wir alle Zeilen einer oder beider Quellen in der verbundenen Menge erscheinen, unabhängig davon, ob sie mit einem Datensatz in der anderen Quelle übereinstimmen.Hier kommen Outer Joins ins Spiel.Ein 'LEFT' Outer Join enthält alle Datensätze aus dem linken Satz, aber nur übereinstimmende Datensätze aus dem rechten Satz.Bei einem RIGHT Outer Join ist es umgekehrt.FULL Outer Joins beinhalten alle Datensätze aus beiden Sets.In allen Outer Joins werden die "Löcher" (die Stellen, an denen ein eingeschlossener Quelldatensatz keine Übereinstimmung im anderen Satz hat) mit NULL aufgefüllt.

Um einen Outer Join zu erstellen, müssen Sie LEFT, RIGHT oder FULL angeben, optional gefolgt vom Schlüsselwort OUTER.

Unten sind die Ergebnisse der verschiedenen Outer Joins, wenn sie auf unsere ursprünglichen Tabellen A und B angewendet werden:

Qualifizierte Joins geben Bedingungen für das Kombinieren von Zeilen an.Dies geschieht entweder explizit in einer ON-Klausel oder implizit in einer USING-Klausel.

Die meisten qualifizierten Joins haben eine ON-Klausel mit einer expliziten Bedingung, die jeder gültige boolesche Ausdruck sein kann, aber normalerweise einen Vergleich zwischen den beiden beteiligten Quellen beinhaltet.

Sehr oft ist die Bedingung ein Gleichheitstest (oder eine Reihe von AND-verknüpften Gleichheitstests) mit dem Operator “=”.Joins wie diese heißen equi-joins.(Die Beispiele im Abschnitt über innere und äußere Verknüpfungen waren alle Gleichverknüpfungen.)

Beispiele für Joins mit einer expliziten Bedingung:

Equi-Joins vergleichen häufig Spalten mit dem gleichen Namen in beiden Tabellen.Wenn dies der Fall ist, können wir auch den zweiten Typ eines qualifizierten Joins verwenden: den benannten Spalten join.

Benannte Spalten-Joins haben eine USING-Klausel, die nur die Spaltennamen angibt.Also stattdessen:

wir können auch schreiben:

was deutlich kürzer ist.Die Ergebnismenge ist jedoch etwas anders — zumindest bei Verwendung von “SELECT *”:

Wenn Sie alle Spalten in der Ergebnismenge der benannten Spalten verknüpfen möchten, richten Sie Ihre Abfrage wie folgt ein:

Dadurch erhalten Sie genau die gleiche Ergebnismenge wie beim Join mit expliziter Bedingung.

Für einen OUTER benannten Spalten-Join gibt es eine zusätzliche Wendung, wenn “SELECT *” oder ein nicht qualifizierter Spaltenname aus der USING-Liste verwendet wird:

Wenn eine Zeile aus einem Quellsatz keine Übereinstimmung im anderen hat, aber aufgrund der Direktiven LEFT, RIGHT oder FULL trotzdem eingeschlossen werden muss, erhält die zusammengeführte Spalte in der verbundenen Menge das Nicht- NULL-Wert.Das ist fair genug, aber jetzt können Sie nicht sagen, ob dieser Wert aus dem linken Satz, dem rechten Satz oder beiden stammt.Dies kann besonders täuschen, wenn der Wert aus dem rechten Satz stammt, da “*” immer kombinierte Spalten im linken Teil anzeigt — auch bei einem RIGHT-Join.

Ob dies ein Problem ist oder nicht, hängt von der Situation ab.Wenn dies der Fall ist, verwenden Sie den oben gezeigten Ansatz “a.*, b.*”, wobei a und b die Namen oder Aliase der beiden Quellen sind.Oder noch besser, vermeiden Sie “*” in Ihren ernsthaften Abfragen und qualifizieren Sie alle Spaltennamen in verbundenen Mengen.Dies hat den zusätzlichen Vorteil, dass Sie sich überlegen müssen, welche Daten Sie woher abrufen möchten.

Es liegt in Ihrer Verantwortung, sicherzustellen, dass die Spaltennamen in der USING-Liste von kompatiblen Typen zwischen den beiden Quellen sind.Wenn die Typen kompatibel, aber nicht gleich sind, konvertiert die Engine sie in den Typ mit dem breitesten Wertebereich, bevor die Werte verglichen werden.Dies ist auch der Datentyp der zusammengeführten Spalte, der in der Ergebnismenge angezeigt wird, wenn “SELECT *” oder der nicht qualifizierte Spaltenname verwendet wird.Qualifizierte Spalten hingegen behalten immer ihren ursprünglichen Datentyp.

Um die Idee des benannten Spalten-Joins noch einen Schritt weiter zu gehen, führt ein natural join einen automatischen Equi-Join für alle Spalten mit dem gleichen Namen in der linken und rechten Tabelle durch.Die Datentypen dieser Spalten müssen kompatibel sein.

Gegeben seien diese beiden Tabellen:

Ein natürlicher Join von TA und TB würde die Spalten a und ins_date beinhalten, und die folgenden beiden Anweisungen hätten den gleichen Effekt:

Wie alle Joins sind natürliche Joins standardmäßig innere Joins, aber Sie können sie in äußere Joins umwandeln, indem Sie LEFT, RIGHT oder FULL vor dem JOIN-Schlüsselwort angeben.

Ein Cross-Join erzeugt das Full-Set-Produkt der beiden Datenquellen.Dies bedeutet, dass jede Zeile in der linken Quelle erfolgreich mit jeder Zeile in der rechten Quelle abgeglichen wird.

Bitte beachten Sie, dass die Kommasyntax veraltet ist!Es wird nur unterstützt, um die Funktionsfähigkeit des Legacy-Codes aufrechtzuerhalten, und kann in einer zukünftigen Version verschwinden.

Das Kreuzverknüpfen zweier Mengen ist äquivalent dazu, sie auf einer Tautologie zu verbinden (eine Bedingung, die immer wahr ist).Die folgenden beiden Aussagen haben die gleiche Wirkung:

Cross-Joins sind Inner-Joins, da sie nur übereinstimmende Datensätze enthalten – es kommt einfach vor, dass jeder Datensatz übereinstimmt!Ein Outer-Cross-Join, falls vorhanden, würde dem Ergebnis nichts hinzufügen, da die hinzugefügten Outer-Joins nicht übereinstimmende Datensätze sind und diese in Cross-Joins nicht vorhanden sind.

Cross-Joins sind selten sinnvoll, außer wenn Sie alle möglichen Kombinationen von zwei oder mehr Variablen auflisten möchten.Angenommen, Sie verkaufen ein Produkt in verschiedenen Größen, Farben und Materialien.Wenn diese Variablen jeweils in einer eigenen Tabelle aufgeführt sind, würde diese Abfrage alle Kombinationen zurückgeben:

Im SQL:89-Standard wurden die an einem Join beteiligten Tabellen als durch Kommas getrennte Liste in der FROM-Klausel angegeben (mit anderen Worten, ein Cross Join ).Die Join-Bedingungen wurden dann neben anderen Suchbegriffen in der WHERE-Klausel angegeben.Diese Art von Join wird als impliziter Join bezeichnet.

Ein Beispiel für einen impliziten Join:

Das Mischen von expliziten und impliziten Joins wird nicht empfohlen, ist jedoch zulässig.Einige Arten des Mischens werden jedoch von Firebird nicht unterstützt.

Die folgende Abfrage gibt beispielsweise den Fehler “Spalte gehört nicht zur referenzierten Tabelle” aus.

Das liegt daran, dass der explizite Join die Tabelle TA nicht sehen kann.Die nächste Abfrage wird jedoch ohne Fehler abgeschlossen, da die Einschränkung nicht verletzt wird.

Der Operator “=”, der explizit in vielen bedingten Joins und implizit in benannten Spalten-Joins und natürlichen Joins verwendet wird, gleicht nur Werte mit Werten ab.Nach dem SQL-Standard ist NULL kein Wert und daher sind zwei NULL weder gleich noch ungleich.Wenn NULLs in einem Join miteinander übereinstimmen müssen, verwenden Sie den IS NOT DISTINCT FROM-Operator.Dieser Operator gibt true zurück, wenn die Operanden den gleichen Wert oder haben, wenn beide NULL sind.

Ebenso in den — extrem seltenen — Fällen, in denen Sie bei inequality beitreten möchten, verwenden Sie IS DISTINCT FROM, nicht “<>”, wenn NULL als anders betrachtet werden soll Wert und zwei NULLs als gleich betrachtet:

Firebird weist nicht qualifizierte Feldnamen in einer Abfrage zurück, wenn diese Feldnamen in mehr als einem an einem Join beteiligten Dataset vorhanden sind.Dies gilt sogar für innere Equi-Joins, bei denen der Feldname in der ON-Klausel wie folgt vorkommt:

Von dieser Regel gibt es eine Ausnahme: Bei Named-Column-Joins und Natural-Joins darf der unqualifizierte Feldname einer am Matching-Prozess beteiligten Spalte legal verwendet werden und bezieht sich auf die gleichnamige zusammengeführte Spalte.Bei Joins mit benannten Spalten sind dies die Spalten, die in der USING-Klausel aufgelistet sind.Bei natürlichen Verknüpfungen sind dies die Spalten, die in beiden Beziehungen denselben Namen haben.Beachten Sie aber bitte noch einmal, dass, insbesondere bei Outer-Joins, ein einfacher colname nicht immer gleich links.colname oder right.colname ist.Typen können unterschiedlich sein und eine der qualifizierten Spalten kann NULL sein, während die andere nicht ist.In diesem Fall kann der Wert in der zusammengeführten, nicht qualifizierten Spalte die Tatsache maskieren, dass einer der Quellwerte fehlt.

Wenn ein Join mit einer Stored Procedure durchgeführt wird, die nicht über Eingabeparameter mit anderen Datenströmen korreliert ist, gibt es keine Merkwürdigkeiten.Wenn Korrelation im Spiel ist, offenbart sich eine unangenehme Eigenart.Das Problem ist, dass sich der Optimierer jede Möglichkeit verweigert, die Zusammenhänge der Eingabeparameter der Prozedur aus den Feldern in den anderen Streams zu ermitteln:

Hier wird die Prozedur ausgeführt, bevor ein einzelner Datensatz aus der Tabelle MY_TAB abgerufen wurde.Der Fehler isc_no_cur_rec error (no current record for fetch operation) wird ausgelöst und unterbricht die Ausführung.

Die Lösung besteht darin, eine Syntax zu verwenden, die die Join-Reihenfolge explizit angibt:

Dies erzwingt, dass die Tabelle vor dem Vorgang gelesen wird und alles funktioniert ordnungsgemäß.

Eine abgeleitete Tabelle, die mit dem Schlüsselwort LATERAL definiert ist, wird als seitlich abgeleitete Tabelle bezeichnet.Wenn eine abgeleitete Tabelle als lateral definiert ist, darf sie auf andere Tabellen in derselben FROM-Klausel verweisen, jedoch nur auf die, die in der FROM-Klausel davor deklariert wurden.

Die WHERE-Klausel dient dazu, die zurückgegebenen Zeilen auf diejenigen zu beschränken, die den Aufrufer interessieren.Die Bedingung, die dem Schlüsselwort WHERE folgt, kann eine einfache Prüfung wie “AMOUNT = 3” sein oder ein vielschichtiger, verschachtelter Ausdruck mit Unterauswahlen, Prädikaten, Funktionsaufrufen, mathematischen und logischen Operatoren, Kontexvariablen und mehr.

Die Bedingung in der WHERE-Klausel wird oft als Suchbedingung, als Suchausdruck oder einfach als Suche bezeichnet.

In DSQL und ESQL kann der Suchausdruck Parameter enthalten.Dies ist sinnvoll, wenn eine Abfrage mit unterschiedlichen Eingabewerten mehrmals wiederholt werden muss.In der SQL-Zeichenfolge, die an den Server übergeben wird, werden Fragezeichen als Platzhalter für die Parameter verwendet.Sie werden positionale Parameter genannt, weil sie nur durch ihre Position im String unterschieden werden können.Konnektivitätsbibliotheken unterstützen oft named parameters der Form :id, :amount, :a usw.Diese sind benutzerfreundlicher;die Bibliothek kümmert sich um die Übersetzung der benannten Parameter in Positionsparameter, bevor die Anweisung an den Server übergeben wird.

Die Suchbedingung kann auch lokale (PSQL) oder Host- (ESQL) Variablennamen enthalten, denen ein Doppelpunkt vorangestellt ist.

Nur die Zeilen, für die die Suchbedingung 'TRUE' ergibt, werden in die Ergebnismenge aufgenommen.Seien Sie vorsichtig mit möglichen NULL-Ergebnissen: Wenn Sie einen NULL-Ausdruck mit NOT negieren, ist das Ergebnis immer noch NULL und die Zeile wird nicht passieren.Dies wird in einem der folgenden Beispiele demonstriert.

Das folgende Beispiel zeigt, was passieren kann, wenn die Suchbedingung NULL ergibt.

Angenommen, Sie haben eine Tabelle mit den Namen einiger Kinder und der Anzahl der Murmeln (engl. marbles), die sie besitzen.Zu einem bestimmten Zeitpunkt enthält die Tabelle diese Daten:

Beachten Sie zunächst den Unterschied zwischen NULL und 0: Fritz hat bekannt überhaupt keine Murmeln, Chris' und Hadassah’s Murmeln sind unbekannt.

Wenn Sie nun diese SQL-Anweisung ausgeben:

Sie erhalten die Namen Anita, Bob E., Eve und Gerry.Diese Kinder haben alle mehr als 10 Murmeln.

Wenn Sie den Ausdruck negieren:

Deirdre, Fritz und Isaac sind an der Reihe, die Liste zu füllen.Chris und Hadassah sind nicht enthalten, da sie nicht bekannt haben, dass sie zehn Murmeln oder weniger haben.Sollten Sie diese letzte Abfrage ändern in:

das Ergebnis bleibt gleich, da der Ausdruck NULL <= 10 UNKNOWN ergibt.Dies ist nicht dasselbe wie TRUE, daher werden Chris und Hadassah nicht aufgeführt.Wenn Sie möchten, dass sie mit den “armen”-Kindern aufgelistet werden, ändern Sie die Abfrage in:

Jetzt wird die Suchbedingung für Chris und Hadassah wahr, da “marbles is null” in ihrem Fall offensichtlich TRUE zurückgibt.Tatsächlich kann die Suchbedingung jetzt für niemanden NULL sein.

Zuletzt zwei Beispiele für SELECT-Abfragen mit Parametern in der Suche.Es hängt von der Anwendung ab, wie Sie Abfrageparameter definieren sollten und ob dies überhaupt möglich ist.Beachten Sie, dass Abfragen wie diese nicht sofort ausgeführt werden können: Sie müssen zuerst vorbereitet werden.Nachdem eine parametrisierte Abfrage erstellt wurde, kann der Benutzer (oder der aufrufende Code) Werte für die Parameter bereitstellen und mehrmals ausführen lassen, wobei vor jedem Aufruf neue Werte eingegeben werden.Wie die Werte eingegeben und die Ausführung gestartet wird, bleibt der Anwendung überlassen.In einer GUI-Umgebung gibt der Benutzer typischerweise die Parameterwerte in ein oder mehrere Textfelder ein und klickt dann auf eine Schaltfläche "Ausführen", "Ausführen" oder "Aktualisieren".

Die letzte Abfrage kann nicht direkt an die Engine übergeben werden; die Anwendung muss es zuerst in das andere Format konvertieren und benannte Parameter Positionsparametern zuordnen.

GROUP BY führt Ausgabezeilen, die dieselbe Kombination von Werten in ihrer Elementliste haben, zu einer einzigen Zeile zusammen.Aggregatfunktionen in der Auswahlliste werden auf jede Gruppe einzeln und nicht auf den gesamten Datensatz angewendet.

Wenn die Auswahlliste nur Aggregatspalten enthält oder allgemeiner Spalten, deren Werte nicht von einzelnen Zeilen in der zugrunde liegenden Menge abhängen, ist GROUP BY optional.Wenn es weggelassen wird, besteht die endgültige Ergebnismenge von aus einer einzelnen Zeile (vorausgesetzt, dass mindestens eine aggregierte Spalte vorhanden ist).

Wenn die Auswahlliste sowohl Aggregatspalten als auch Spalten enthält, deren Werte pro Zeile variieren können, wird die GROUP BY-Klausel obligatorisch.

Als allgemeine Faustregel gilt, dass jedes nicht aggregierte Element in der SELECT-Liste auch in der GROUP BY-Liste enthalten sein muss.Sie können dies auf drei Arten tun:

Zusätzlich zu den erforderlichen Elementen kann die Gruppierungsliste auch Folgendes enthalten:

Wenn die Auswahlliste nur aggregierte Spalten enthält, ist GROUP BY nicht obligatorisch:

Dadurch wird eine einzelne Zeile zurückgegeben, die die Anzahl der männlichen Studenten und ihr Durchschnittsalter auflistet.Das Hinzufügen von Ausdrücken, die nicht von Werten in einzelnen Zeilen der Tabelle STUDENTS abhängen, ändert daran nichts:

Die Zeile enthält jetzt eine zusätzliche Spalte mit dem aktuellen Datum, aber ansonsten hat sich nichts Wesentliches geändert.Eine GROUP BY-Klausel ist weiterhin nicht erforderlich.

In beiden obigen Beispielen ist es jedoch erlaubt.Das ist vollkommen gültig:

Dadurch wird für jede Klasse mit Jungen eine Zeile zurückgegeben, in der die Anzahl der Jungen und ihr Durchschnittsalter in dieser bestimmten Klasse aufgeführt sind.(Wenn Sie auch das Feld current_date belassen, wird dieser Wert in jeder Zeile wiederholt, was nicht sehr aufregend ist.)

Die obige Abfrage hat jedoch einen großen Nachteil: Sie gibt Ihnen Informationen über die verschiedenen Klassen, aber sie sagt Ihnen nicht, welche Zeile für welche Klasse gilt.Um diese zusätzlichen Informationen zu erhalten, muss die nicht aggregierte Spalte "CLASS" zur Auswahlliste hinzugefügt werden:

Jetzt haben wir eine nützliche Abfrage.Beachten Sie, dass das Hinzufügen der Spalte CLASS auch die GROUP BY-Klausel obligatorisch macht.Wir können diese Klausel nicht mehr löschen, es sei denn, wir entfernen auch CLASS aus der Spaltenliste.

Die Ausgabe unserer letzten Abfrage kann etwa so aussehen:

Die Überschriften “COUNT” und “AVG” sind wenig aussagekräftig.In einem einfachen Fall wie diesem kommen Sie vielleicht damit durch, aber im Allgemeinen sollten Sie Aggregatspalten einen aussagekräftigen Namen geben, indem Sie sie mit einem Alias versehen:

Wie Sie sich vielleicht an der formalen Syntax der Spaltenliste erinnern, ist das Schlüsselwort AS optional.

Das Hinzufügen weiterer nicht-aggregierter (oder besser: zeilenabhängiger) Spalten erfordert auch das Hinzufügen dieser zur GROUP BY-Klausel.Zum Beispiel möchten Sie vielleicht die oben genannten Informationen auch für Mädchen sehen;und vielleicht möchten Sie auch zwischen Internats- und Tagesschülern unterscheiden:

Dies kann zu folgendem Ergebnis führen:

Jede Zeile in der Ergebnismenge entspricht einer bestimmten Kombination der Spalten CLASS, SEX und BOARDING_TYPE.Die aggregierten Ergebnisse – Anzahl und Durchschnittsalter – werden für jede dieser eher spezifischen Gruppen einzeln angegeben.In einer Abfrage wie dieser sehen Sie keine Gesamtsumme für Jungen als Ganzes oder Tagesschüler als Ganzes.Das ist der Kompromiss: Je mehr nicht aggregierte Spalten Sie hinzufügen, desto mehr können Sie sehr spezifische Gruppen lokalisieren, aber desto mehr verlieren Sie auch den Überblick.Natürlich können Sie die “gröberen” Aggregate weiterhin durch separate Abfragen erhalten.

So wie eine 'WHERE'-Klausel die Zeilen in einem Datensatz auf diejenigen beschränkt, die die Suchbedingung erfüllen, so erlegt die 'HAVING'-Unterklausel Beschränkungen für die aggregierten Zeilen in einer gruppierten Menge auf.HAVING ist optional und kann nur in Verbindung mit GROUP BY verwendet werden.

Die Bedingung(en) in der HAVING-Klausel können sich beziehen auf:

Eine HAVING-Klausel kann nicht enthalten:

Aufbauend auf unseren früheren Beispielen könnte dies verwendet werden, um kleine Schülergruppen zu überspringen:

So wählen Sie nur Gruppen mit einer Mindestaltersspanne aus:

Beachten Sie, dass Sie, wenn Sie wirklich an diesen Informationen interessiert sind, normalerweise min(age) und max(age) einschließen würden – oder den Ausdruck „`max(age) - min(age) `" – auch in der Auswahlliste!

Um nur 3. Klassen einzubeziehen:

Besser wäre es, diese Bedingung in die WHERE-Klausel zu verschieben:

Die WINDOW-Klausel definiert ein oder mehrere benannte Fenster, auf die von Fensterfunktionen in der aktuellen Abfragespezifikation verwiesen werden kann.

In einer Abfrage mit mehreren SELECT- und WINDOW-Klauseln (zB mit Unterabfragen) ist der Geltungsbereich von `new_window_name_ auf seinen Abfragekontext beschränkt.Das bedeutet, dass ein Fenstername aus einem inneren Kontext nicht in einem äußeren Kontext verwendet werden kann und umgekehrt.Derselbe Fenstername kann jedoch unabhängig in verschiedenen Kontexten verwendet werden, obwohl es besser sein könnte, dies zu vermeiden, um Verwirrung zu vermeiden.

Weitere Informationen finden Sie unter [fblangref40-windowfuncs-de].

Die PLAN-Klausel ermöglicht es dem Benutzer, einen Datenabrufplan zu übermitteln und damit den Plan zu überschreiben, den der Optimierer automatisch generiert hätte.

Jedes Mal, wenn ein Benutzer eine Abfrage an die Firebird-Engine sendet, berechnet der Optimierer eine Datenabrufstrategie.Die meisten Firebird-Clients können diesen Abrufplan für den Benutzer sichtbar machen.In Firebirds eigenem Dienstprogramm isql geschieht dies mit dem Befehl SET PLAN ON.Wenn Sie Abfragepläne untersuchen, anstatt Abfragen auszuführen, zeigt SET PLANONLY ON den Plan an, ohne die Abfrage auszuführen.Verwenden Sie SET PLANONLY OFF, um die Abfrage auszuführen und den Plan anzuzeigen.

In den meisten Situationen können Sie darauf vertrauen, dass Firebird den optimalen Abfrageplan für Sie auswählt.Wenn Sie jedoch komplizierte Abfragen haben, deren Leistung nicht ausreicht, kann es sich durchaus lohnen, den Plan zu prüfen und zu prüfen, ob Sie ihn verbessern können.

Die einfachsten Pläne bestehen nur aus einem Relationsnamen gefolgt von einer Abrufmethode.Zum Beispiel für eine unsortierte Einzeltabellenauswahl ohne WHERE-Klausel:

Erweiterter Plan:

Wenn es eine WHERE- oder eine HAVING-Klausel gibt, können Sie den Index angeben, der für die Suche nach Übereinstimmungen verwendet werden soll:

Erweiterter Plan:

Die Direktive INDEX wird auch für Join-Bedingungen verwendet (wird etwas später besprochen).Es kann eine durch Kommas getrennte Liste von Indizes enthalten.

ORDER gibt den Index zum Sortieren der Menge an, wenn eine ORDER BY- oder GROUP BY-Klausel vorhanden ist:

Erweiterter plan:

ORDER und INDEX können kombiniert werden:

Erweiterter Plan:

Es ist vollkommen in Ordnung, wenn ORDER und INDEX denselben Index angeben:

Erweiterter Plan:

Um Sets zu sortieren, wenn kein verwendbarer Index verfügbar ist (oder wenn Sie seine Verwendung unterdrücken möchten), lassen Sie ORDER weg und stellen Sie dem Planausdruck SORT voran:

Erweiterter Plan:

Oder wenn ein Index für die Suche verwendet wird:

Erweiterter Plan:

Beachten Sie, dass SORT im Gegensatz zu ORDER außerhalb der Klammern steht.Dies spiegelt die Tatsache wider, dass die Datenzeilen ungeordnet abgerufen und anschließend von der Engine sortiert werden.

Geben Sie bei der Auswahl aus einer Ansicht die Ansicht und die betreffende Tabelle an.Wenn Sie beispielsweise eine Ansicht FRESHMEN haben, die nur die Erstsemester auswählt:

Erweiterter Plan:

Oder zum Beispiel:

Erweiterter Plan:

Bei einem Join können Sie den Index angeben, der für den Abgleich verwendet werden soll.Sie müssen auch die JOIN-Direktive für die beiden Streams im Plan verwenden:

Erweiterter Plan:

Dieselbe Verknüpfung, sortiert nach einer indizierten Spalte:

Erweiterter Plan:

Und für eine nicht indizierte Spalte:

Erweiterter Plan:

Mit einer hinzugefügten Suchbedingung:

Erweiterter Plan:

Als Left Outer Join:

Erweiterter Plan:

Wenn keine Indizes verfügbar sind, die der Join-Bedingung entsprechen (oder wenn Sie sie nicht verwenden möchten), können Sie die Streams mit der Methode HASH oder MERGE verbinden.

Um eine Verbindung mit der HASH-Methode im Plan herzustellen, wird die HASH-Direktive anstelle der JOIN-Direktive verwendet.In diesem Fall wird der kleinere (sekundäre) Strom vollständig in einem internen Puffer materialisiert.Beim Lesen dieses sekundären Streams wird eine Hash-Funktion angewendet und ein Paar {Hash, Zeiger auf Puffer} in eine Hash-Tabelle geschrieben.Dann wird der primäre Stream gelesen und sein Hash-Schlüssel wird gegen die Hash-Tabelle getestet.

Erweiterter Plan:

Für einen 'MERGE'-Join muss der Plan zuerst beide Streams in deren Join-Spalte(n) sortieren und dann zusammenführen.Dies wird mit der SORT-Direktive (die wir bereits gesehen haben) und MERGE statt JOIN erreicht:

Das Hinzufügen einer ORDER BY-Klausel bedeutet, dass das Ergebnis der Zusammenführung ebenfalls sortiert werden muss:

Schließlich fügen wir eine Suchbedingung für zwei indizierbare Spalten der Tabelle STUDENTS hinzu:

Wie aus der formalen Syntaxdefinition hervorgeht, können JOINs und MERGEs im Plan mehr als zwei Streams kombinieren.Außerdem kann jeder Planausdruck als Planelement in einem umfassenden Plan verwendet werden.Dies bedeutet, dass Pläne bestimmter komplizierter Abfragen verschiedene Verschachtelungsebenen haben können.

Schließlich können Sie statt MERGE auch SORT MERGE schreiben.Da dies absolut keinen Unterschied macht und zu Verwirrung mit “real” SORT-Direktiven führen kann (die einen Unterschied machen), ist es wahrscheinlich am besten, beim einfachen MERGE zu bleiben.

Neben dem Plan für die Hauptabfrage können Sie für jede Unterabfrage einen Plan angeben.Die folgende Abfrage mit mehreren Plänen funktioniert beispielsweise:

Die UNION-Klausel verkettet zwei oder mehr Datensätze und erhöht somit die Anzahl der Zeilen, aber nicht die Anzahl der Spalten.Datensätze, die an einer UNION teilnehmen, müssen die gleiche Anzahl von Spalten haben und die Spalten an den entsprechenden Positionen müssen vom gleichen Typ sein.Abgesehen davon können sie völlig unabhängig sein.

Standardmäßig unterdrückt eine Vereinigung doppelte Zeilen.UNION ALL zeigt alle Zeilen, einschließlich aller Duplikate.Das optionale Schlüsselwort DISTINCT macht das Standardverhalten explizit.

Unions beziehen ihre Spaltennamen aus der ersten Auswahlabfrage.Wenn Sie Union-Spalten mit einem Alias versehen möchten, tun Sie dies in der Spaltenliste des obersten SELECT.Aliase in anderen teilnehmenden Selects sind erlaubt und können sogar nützlich sein, werden aber nicht auf Gewerkschaftsebene verbreitet.

Wenn eine Union eine ORDER BY-Klausel hat, sind die einzigen zulässigen Sortierelemente Integer-Literale, die 1-basierte Spaltenpositionen angeben, optional gefolgt von einem ASC/DESC und/oder einem NULLS {FIRST | LAST}-Anweisung.Dies impliziert auch, dass Sie eine Union nicht nach etwas sortieren können, das keine Spalte in der Union ist.(Sie können es jedoch in eine abgeleitete Tabelle einschließen, die Ihnen alle üblichen Sortieroptionen zurückgibt.)

Unions sind in Unterabfragen jeglicher Art erlaubt und können selbst Unterabfragen enthalten.Sie können auch Joins enthalten und an einem Join teilnehmen, wenn sie in eine abgeleitete Tabelle eingeschlossen sind.

Diese Abfrage präsentiert Informationen aus verschiedenen Musiksammlungen in einem Datensatz unter Verwendung von Unions:

Wenn id, title, artist und length die einzigen beteiligten Felder in den Tabellen sind, kann die Abfrage auch so geschrieben werden:

Die Qualifizierung der “Sterne” ist hier notwendig, da sie nicht das einzige Element in der Spaltenliste sind.Beachten Sie, dass die Aliase “c” in der ersten und dritten Auswahl nicht miteinander in Konflikt geraten: Ihre Gültigkeitsbereiche sind nicht unionsweit, sondern gelten nur für ihre jeweiligen select-Abfragen.

Die nächste Abfrage ruft Namen und Telefonnummern von Übersetzern und Korrektoren ab.Übersetzer, die auch als Korrektoren tätig sind, erscheinen nur einmal in der Ergebnismenge, sofern ihre Telefonnummer in beiden Tabellen gleich ist.Das gleiche Ergebnis kann ohne DISTINCT erreicht werden.Mit ALL würden diese Personen zweimal erscheinen.

Eine UNION innerhalb einer Unterabfrage:

Die VALUES-Liste muss für jede Spalte in der Spaltenliste einen Wert in der gleichen Reihenfolge und vom richtigen Typ liefern.Die Spaltenliste muss nicht jede Spalte im Ziel angeben, aber wenn die Spaltenliste nicht vorhanden ist, benötigt die Engine einen Wert für jede Spalte in der Tabelle oder Ansicht (ohne berechnete Spalten).

Der Wert DEFAULT ermöglicht die Angabe einer Spalte in der Spaltenliste, weist Firebird jedoch an, den Standardwert zu verwenden (entweder NULL oder der in der DEFAULT-Klausel der Spaltendefinition angegebene Wert).Bei Identitätsspalten wird durch die Angabe von DEFAULT der Identitätswert generiert.Es ist möglich, berechnete Spalten in die Spaltenliste aufzunehmen und DEFAULT als Spaltenwert anzugeben.

Bei dieser Einfügemethode müssen die Ausgabespalten der SELECT-Anweisung für jede Zielspalte in der Spaltenliste einen Wert in der gleichen Reihenfolge und vom richtigen Typ liefern.

Literale Werte, Kontextvariablen oder Ausdrücke kompatiblen Typs können für jede Spalte in der Quellzeile ersetzt werden.In diesem Fall werden eine Quellspaltenliste und eine entsprechende VALUES-Liste benötigt.

Wenn die Spaltenliste fehlt – wie bei der Verwendung von SELECT * für den Quellausdruck – muss die column_list die Namen jeder Spalte in der Zieltabelle oder Sicht enthalten (berechnete Spalten ausgeschlossen).

Natürlich müssen die Spaltennamen in der Quelltabelle nicht mit denen in der Zieltabelle übereinstimmen.Jede Art von SELECT-Anweisung ist zulässig, solange ihre Ausgabespalten in Anzahl, Reihenfolge und Typ genau mit den Einfügespalten übereinstimmen.Typen müssen nicht exakt gleich sein, aber sie müssen zuweisungskompatibel sein.

Die DEFAULT VALUES-Klausel ermöglicht das Einfügen eines Datensatzes, ohne irgendwelche Werte bereitzustellen, entweder direkt oder aus einer SELECT-Anweisung.Dies ist nur möglich, wenn jede NOT NULL- oder CHECK-Spalte in der Tabelle entweder einen gültigen Standardwert deklariert hat oder einen solchen Wert von einem BEFORE INSERT-Trigger erhält.Darüber hinaus dürfen Trigger, die erforderliche Feldwerte bereitstellen, nicht vom Vorhandensein von Eingabewerten abhängen.

Die Angabe von DEFAULT VALUES entspricht der Angabe einer Werteliste mit dem Wert DEFAULT für alle Spalten.

Die Klausel OVERRIDING steuert das Verhalten einer Identitätsspalte nur für diese Anweisung.

Eine INSERT-Anweisung, die höchstens eine Zeile hinzufügt, kann optional eine RETURNING-Klausel enthalten, um Werte aus der eingefügten Zeile zurückzugeben.Die Klausel muss, falls vorhanden, nicht alle Einfügespalten enthalten und kann auch andere Spalten oder Ausdrücke enthalten.Die zurückgegebenen Werte spiegeln alle Änderungen wider, die möglicherweise an BEFORE INSERT-Triggern vorgenommen wurden.

Der Benutzer, der die Anweisung ausführt, benötigt SELECT-Berechtigungen für die in der RETURNING-Klausel angegebenen Spalten.

Die Syntax der returning_list ähnelt der Spaltenliste einer SELECT-Klausel.Es ist möglich, alle Spalten mit * oder table_name.* zu referenzieren.

Die optionale Unterklausel INTO ist nur in PSQL gültig.

Das Einfügen in 'BLOB'-Spalten ist nur unter folgenden Umständen möglich:

Wenn Sie einer Tabelle oder Sicht einen Alias zuweisen, muss der Alias bei der Angabe von Spalten und auch in allen Spaltenreferenzen in anderen Klauseln verwendet werden.

Korrekte Verwendung

Nicht möglich:

In der SET-Klausel werden die Zuweisungsphrasen, die die Spalten mit den zu setzenden Werten enthalten, durch Kommas getrennt.In einer Zuweisungsphrase befinden sich links die Spaltennamen und rechts die Werte oder Ausdrücke, die die Zuweisungswerte enthalten.Eine Spalte darf nur einmal in der SET-Klausel enthalten sein.

In Ausdrücken auf der rechten Seite kann ein Spaltenname verwendet werden.In diesen Werten auf der rechten Seite wird immer der alte Wert der Spalte verwendet, auch wenn der Spalte bereits früher in der SET-Klausel ein neuer Wert zugewiesen wurde.

Die Verwendung des Wertes DEFAULT setzt die Spalte auf ihren Standardwert (entweder NULL oder der in der DEFAULT-Klausel der Spaltendefinition angegebene Wert).Für eine Identitätsspalte wird durch die Angabe von DEFAULT ein neuer Identitätswert generiert.Es ist möglich, berechnete Spalten in der SET-Klausel zu “aktualisieren”, wenn und nur wenn der zugewiesene Wert DEFAULT ist.

Daten in der TSET-Tabelle:

Die Anweisung:

ändert die Werte in:

Beachten Sie, dass die alten Werte (1 und 2) verwendet werden, um die Spalte b zu aktualisieren, auch nachdem der Spalte ein neuer Wert zugewiesen wurde (5).

Die WHERE-Klausel legt die Bedingungen fest, die die Menge der Datensätze für ein searched update begrenzen.

Wenn in PSQL ein benannter Cursor zum Aktualisieren einer Menge verwendet wird, ist die Aktion mit der WHERE CURRENT OF-Klausel auf die Zeile beschränkt, in der sich der Cursor gerade befindet.Dies ist ein positioniertes Update.

Für String-Literale, bei denen der Parser Hilfe benötigt, um den Zeichensatz der Daten zu interpretieren, kann die Introducer-Syntax verwendet werden.Dem Zeichenfolgenliteral geht der Zeichensatzname voran, dem ein Unterstrich vorangestellt ist:

Die Klauseln ORDER BY und ROWS sind nur sinnvoll, wenn sie zusammen verwendet werden.Sie können jedoch separat verwendet werden.

Wenn ROWS ein Argument hat, m, werden die zu aktualisierenden Zeilen auf die ersten m Zeilen beschränkt.

Wenn zwei Argumente verwendet werden, m und n, begrenzt ROWS die Zeilen, die aktualisiert werden, auf Zeilen von m bis einschließlich n.Beide Argumente sind ganze Zahlen und beginnen bei 1.

Eine UPDATE-Anweisung, die höchstens eine Zeile umfasst, kann RETURNING enthalten, um einige Werte aus der aktualisierten Zeile zurückzugeben."RETURNING" kann Daten aus einer beliebigen Spalte der Zeile enthalten, nicht unbedingt aus den Spalten, die gerade aktualisiert werden.Es kann Literale oder Ausdrücke enthalten, die nicht mit Spalten verknüpft sind, wenn dies erforderlich ist.

Der Benutzer, der die Anweisung ausführt, benötigt SELECT-Berechtigungen für die in der RETURNING-Klausel angegebenen Spalten.

Wenn das RETURNING-Set Daten aus der aktuellen Zeile enthält, melden die zurückgegebenen Werte Änderungen, die in den BEFORE UPDATE-Triggern vorgenommen wurden, aber nicht die in AFTER UPDATE-Triggern.

Als Spaltennamen können die Kontextvariablen OLD.fieldname und NEW.fieldname verwendet werden.Wenn OLD. oder NEW. nicht angegeben wird, sind die zurückgegebenen Spaltenwerte die NEW.-Werte.

Die Syntax der returning_list ähnelt der Spaltenliste einer SELECT-Klausel.Es ist möglich, alle Spalten mit * oder table_name.*, NEW.* und/oder OLD.* zu referenzieren.

In DSQL gibt eine Anweisung mit RETURNING immer eine einzelne Zeile zurück.Versuche, ein UPDATE …​ RETURNING …​ auszuführen, das mehrere Zeilen betrifft, führen zu dem Fehler “multiple rows in singleton select”.Wenn die Anweisung keine Datensätze aktualisiert, enthalten die zurückgegebenen Werte NULL.Dieses Verhalten kann sich in zukünftigen Firebird-Versionen ändern.

In PSQL kann die INTO-Klausel verwendet werden, um die Rückgabewerte an lokale Variablen zu übergeben.Es ist in DSQL nicht verfügbar.Wenn keine Datensätze aktualisiert werden, wird nichts zurückgegeben und die in RETURNING angegebenen Variablen behalten ihre vorherigen Werte.

Das Aktualisieren einer BLOB-Spalte ersetzt immer den gesamten Inhalt.Sogar die BLOB ID, das “handle”, das direkt in der Spalte gespeichert wird, wird geändert.BLOBs können aktualisiert werden, wenn:

Die optionale RETURNING-Klausel, falls vorhanden, muss nicht alle in der Anweisung erwähnten Spalten enthalten und kann auch andere Spalten oder Ausdrücke enthalten.Die zurückgegebenen Werte spiegeln alle Änderungen wider, die möglicherweise in BEFORE-Triggern vorgenommen wurden, aber nicht in AFTER-Triggern. OLD.fieldname und NEW.fieldname können beide in der Liste der zurückzugebenden Spalten verwendet werden;für Feldnamen, denen keiner von diesen vorangeht, wird der neue Wert zurückgegeben.

Der Benutzer, der die Anweisung ausführt, benötigt SELECT-Berechtigungen für die in der RETURNING-Klausel angegebenen Spalten.

Die Syntax der returning_list ähnelt der Spaltenliste einer SELECT-Klausel.Es ist möglich, alle Spalten mit * oder table_name.*, NEW.* und/oder OLD.* zu referenzieren.

In DSQL gibt eine Anweisung mit einer RETURNING-Klausel immer genau eine Zeile zurück.Wenn eine RETURNING-Klausel vorhanden ist und mehr als ein übereinstimmender Datensatz gefunden wird, wird ein Fehler “multiple rows in singleton select” ausgegeben.Dieses Verhalten kann sich in einer späteren Version von Firebird ändern.

Die optionale Unterklausel INTO ist nur in PSQL gültig.

Ändern von Daten in einer Tabelle mit UPDATE OR INSERT in einem PSQL-Modul.Der Rückgabewert wird an eine lokale Variable übergeben, deren Doppelpunkt-Präfix optional ist.

Wenn für die Zieltabelle oder -sicht ein Alias angegeben wird, muss dieser verwendet werden, um alle Feldnamenreferenzen in der DELETE-Anweisung zu qualifizieren.

Unterstützte Nutzung:

Nicht möglich:

Die WHERE-Klausel legt die Bedingungen fest, die die Menge der Datensätze für ein searched delete begrenzen.

Wenn in PSQL ein benannter Cursor zum Löschen einer Menge verwendet wird, ist die Aktion mit der Klausel WHERE CURRENT OF auf die Zeile beschränkt, in der sich der Cursor gerade befindet.Dies ist ein positioniertes Löschen.

Eine PLAN-Klausel ermöglicht es dem Benutzer, die Operation manuell zu optimieren.

Die ORDER BY-Klausel ordnet die Menge, bevor das eigentliche Löschen stattfindet.Es macht nur in Kombination mit ROWS Sinn, ist aber auch ohne gültig.

Die ROWS-Klausel begrenzt die Anzahl der zu löschenden Zeilen.Für die Argumente m und n können ganzzahlige Literale oder beliebige ganzzahlige Ausdrücke verwendet werden.

Wenn ROWS ein Argument hat, m, werden die zu löschenden Zeilen auf die ersten m Zeilen beschränkt.

Wenn zwei Argumente verwendet werden, m und n, begrenzt ROWS die zu löschenden Zeilen auf Zeilen von m bis einschließlich n.Beide Argumente sind ganze Zahlen und beginnen bei 1.

Löschen des ältesten Kaufs:

Löschen des/der höchsten Custno(s):

Löschen aller Verkäufe, ORDER BY-Klausel sinnlos:

Löschen eines Datensatzes am Ende beginnend, also ab Z…​:

Löschen der fünf ältesten Gruppen:

Da keine Sortierung (ORDER BY) angegeben ist, werden 8 gefundene Datensätze, beginnend mit dem fünften, gelöscht:

Eine DELETE-Anweisung, die höchstens eine Zeile entfernt, kann optional eine RETURNING-Klausel enthalten, um Werte aus der gelöschten Zeile zurückzugeben.Die Klausel, falls vorhanden, muss nicht alle Spalten der Relation enthalten und kann auch andere Spalten oder Ausdrücke enthalten.

Der Benutzer, der die Anweisung ausführt, benötigt SELECT-Berechtigungen für die in der RETURNING-Klausel angegebenen Spalten.

Die Syntax der returning_list ähnelt der Spaltenliste einer SELECT-Klausel.Es ist möglich, alle Spalten mit * oder table_name.* zu referenzieren.

Eine MERGE-Anweisung, die höchstens eine Zeile betrifft, kann eine RETURNING-Klausel enthalten, um hinzugefügte, geänderte oder entfernte Werte zurückzugeben.Wenn eine RETURNING-Klausel vorhanden ist und mehr als ein übereinstimmender Datensatz gefunden wird, wird ein Fehler “multiple rows in singleton select” ausgegeben.Die RETURNING-Klausel kann beliebige Spalten aus der Zieltabelle (oder aktualisierbaren View) sowie andere Spalten (zB aus der Quelle) und Ausdrücke enthalten.

Der Benutzer, der die Anweisung ausführt, benötigt SELECT-Berechtigungen für die in der RETURNING-Klausel angegebenen Spalten.

Die optionale Unterklausel INTO ist nur in PSQL gültig.

Spaltennamen können durch das Präfix "OLD" oder "NEW" qualifiziert werden, um genau zu definieren, welcher Wert zurückgegeben werden soll: vor oder nach der Änderung. Die zurückgegebenen Werte enthalten die Änderungen, die von BEFORE-Triggern vorgenommen wurden.

Die Syntax der returning_list ähnelt der Spaltenliste einer SELECT-Klausel.Es ist möglich, alle Spalten mit * oder table_name.*, NEW.* und/oder OLD.* zu referenzieren.

Für die Aktion UPDATE oder INSERT verhalten sich unqualifizierte Spaltennamen oder solche, die durch den Zieltabellennamen oder Alias qualifiziert sind, als ob sie durch NEW qualifiziert wären, während sie für die DELETE Aktion wie durch OLD qualifiziert wären.

Das folgende Beispiel modifiziert das vorherige Beispiel, um eine Zeile zu betreffen, und fügt eine RETURNING-Klausel hinzu, um die alte und neue Warenmenge sowie die Differenz zwischen diesen Werten zurückzugeben.

[fblangref40-dml-select-de], [fblangref40-dml-insert-de], [fblangref40-dml-update-de], [fblangref40-dml-update-or-insert-de], [fblangref40-dml-delete-de]

Die EXECUTE PROCEDURE-Anweisung wird am häufigsten verwendet, um den Stil gespeicherter Prozeduren aufzurufen, die geschrieben werden, um auf der Serverseite eine Aufgabe zur Datenänderung auszuführen – solche, die keine SUSPEND-Anweisungen in ihrem Code enthalten.Sie können so konzipiert sein, dass sie eine Ergebnismenge, die nur aus einer Zeile besteht, die normalerweise über einen Satz von RETURNING_VALUES()-Variablen an eine andere gespeicherte Prozedur übergeben wird, die sie aufruft, zurückgeben.Clientschnittstellen verfügen normalerweise über einen API-Wrapper, der die Ausgabewerte in einen Einzelzeilenpuffer abrufen kann, wenn EXECUTE PROCEDURE in DSQL aufgerufen wird.

Das Aufrufen des anderen Stils von Stored Procedures - einer “selectable” - ist mit EXECUTE PROCEDURE möglich, aber es gibt nur die erste Zeile eines Ausgabesatzes zurück, der mit ziemlicher Sicherheit mehrzeilig ist.Auswählbare gespeicherte Prozeduren sind so konzipiert, dass sie durch eine SELECT-Anweisung aufgerufen werden und eine Ausgabe erzeugen, die sich wie eine virtuelle Tabelle verhält.

Die Ausführung eines Blocks ohne Eingabeparameter sollte mit jedem Firebird-Client möglich sein, der es dem Benutzer erlaubt, eigene DSQL-Anweisungen einzugeben.Wenn es Eingabeparameter gibt, wird es schwieriger: Diese Parameter müssen ihre Werte erhalten, nachdem die Anweisung vorbereitet wurde, aber bevor sie ausgeführt wird.Dies erfordert besondere Vorkehrungen, die nicht jede Client-Anwendung bietet.(Firebirds eigenes isql zum Beispiel nicht.)

Der Server akzeptiert nur Fragezeichen (“?”) als Platzhalter für die Eingabewerte, nicht “:a”, “:MyParam” etc., oder wörtliche Werte.Client-Software unterstützt jedoch möglicherweise das Formular “:xxx” und wird es vorverarbeiten, bevor es an den Server gesendet wird.

Wenn der Block Ausgangsparameter hat, muss Sie SUSPEND verwenden, sonst wird nichts zurückgegeben.

Die Ausgabe wird immer in Form einer Ergebnismenge zurückgegeben, genau wie bei einer SELECT-Anweisung.Sie können RETURNING_VALUES nicht verwenden oder den Block INTO einige Variablen ausführen, selbst wenn es nur eine Ergebniszeile gibt.

Einige Editoren für SQL-Anweisungen – insbesondere das Dienstprogramm isql, das mit Firebird geliefert wird, und möglicherweise einige Editoren von Drittanbietern – verwenden eine interne Konvention, die erfordert, dass alle Anweisungen mit einem Semikolon abgeschlossen werden.Dies führt beim Codieren in diesen Umgebungen zu einem Konflikt mit der PSQL-Syntax.Wenn Sie dieses Problem und seine Lösung nicht kennen, lesen Sie bitte die Details im PSQL-Kapitel im Abschnitt Terminator in isql umschalten.