Views werden in SQL dazu
verwendet, häufig verwendete Abfragen nicht immer wieder neu schreiben zu
müssen. Im Grunde ist eine VIEW (auf Deutsch eine sogenannte „Sicht“) nichts
anderes als eine Tabelle in Form eines vordefinierten SQL Statements.
Was kann man mit einer VIEW machen?
Eine VIEW ist eine
virtuelle Tabelle; man kann sie wie eine normale Tabelle verwenden. Man kann
mit einem SELECT-Statement den Inhalt dieser virtuellen Tabelle abfragen,
Einschränkungen im WHERE definieren, theoretisch kann man VIEWS sogar
miteinander verjoinen; das sollte man aber nach Möglichkeit unterlassen – je nach
Komplexität der VIEWS kann sich das negative auf die Performance auswirken.
Verjoinen wir VIEWS, in denen sich bereits JOINS befinden, kann das in eine
regelrechte Performance-Katastrophe ausarten.
Wie bei einer „richtigen“
Tabelle können wir aber auch INSERT, UPDATE und DELETE über eine VIEW
durchführen (sofern wir die Berechtigungen dafür haben). Solche INSERTs, UPDATEs
oder DELETEs landen dann nicht nur in der eigentlichen VIEW, abgekoppelt von
der Datenbank, sondern in der betreffenden Datenbanktabelle selbst!
Wie funktioniert das mit dem Einfügen in VIEWs?
In eine VIEW können wir genauso
wie in eine „normale“ Tabelle mittels INSERT INTO Daten einfügen.
Was ist jetzt also dieses WITH CHECK OPTION?
Da wir über eine VIEW Werte
in eine Tabelle einfügen können, könnte es passieren, dass wir Daten einfügen,
die von der VIEW gar nicht erfasst werden! Um solche Inkonsistenzen zu
vermeiden gibt es die Anweisung WITH CHECK OPTION. Sie sorgt dafür, dass wir
über die VIEW nur Datensätze einfügen können, die von der VIEW auch erfasst werden.
In die eigentliche Tabelle
können wir trotzdem ganz normal auch solche Datensätze einfügen, die von der
VIEW nicht erfasst werden, aber eben nicht mehr über die VIEW.
Sehen wir uns das an einem
einfachen Beispiel an:
Zunächst erstellen wir unsere
Testtabelle in unserer Testdatenbank:
Dann befüllen wir sie mit
ein paar wenigen Testdaten:
Dann erstellen wir eine
VIEW, zunächst ohne die WITH CHECK OPTION-Anweisung:
Es sollen also von der VIEW
nur diejenigen ausgegeben werden, bei denen das Alter NOT NULL ist, also wo ein
Alter dabeisteht. Bis jetzt haben noch alle (drei) in unserer Tabelle ein Alter
angegeben, die VIEW gibt uns den gesamten Inhalt dieser Tabelle aus.
Jetzt fügen wir über die VIEW neue Daten in die Tabelle ein:
Wenn wir jetzt einen Blick
in die TABELLE werfen, sehen wir, dass diese neuen Datensätze auch tatsächlich
in der Tabelle gelandet sind:
Wir haben also über die
VIEW einen Datensatz eingefügt, der von der VIEW selbst gar nicht erfasst wird:
Im Vergleich dazu das Ganze WITH CHECK OPTION
Damit uns so etwas nicht
passieren kann, gibt es WITH CHECK OPTION.
Das gleiche Beispiel noch
einmal; wir erstellen jetzt eine neue VIEW, einziger Unterschied: Diesmal
verwenden wir WITH CHECK OPTION.
Auch über diese VIEW können
wir Datensätze einfügen:
…aber eben nur, sofern sie
von der VIEW auch erfasst werden. Wenn wir versuchen, einen Datensatz einzufügen,
bei dem age NULL ist…
…bekommen wir jetzt eine
Fehlermeldung:
The attempted insert or update
failed because the target view either specifies WITH CHECK OPTION or spans a
view that specifies WITH CHECK OPTION and one or more rows resulting from the
operation did not qualify under the CHECK OPTION constraint.
CHECK OPTION
hat erfolgreich verhindert, dass wir einen Datensatz einfügen, der von der VIEW
nicht erfasst wird.
In die Tabelle
selbst können wir selbstverständlich nach wie vor Datensätze einfügen,
unabhängig vom CHECK OPTION der VIEW:
Das ist kein
Problem, der Datensatz wird korrekt in unsere Testtabelle übernommen:
…und auch die
VIEW gibt korrekt nur die Datensätze aus, die ihren WHERE-Einschränkungen
entsprechen, also in unserem Fall die, wo das Alter NOT NULL ist:
Falls Ihr Euch
gerne weiter mit SQL auseinandersetzen möchtet, sehen wir uns vielleicht in
einem unserer Kurse zum Thema SQL!