Am 14. September 2017 haben wir eine überarbeitete Fassung unserer Datenschutzrichtlinie veröffentlicht. Wenn Sie video2brain.com weiterhin nutzen, erklären Sie sich mit diesem überarbeiteten Dokument einverstanden. Bitte lesen Sie es deshalb sorgfältig durch.

SQL Server 2016: Triggers, Stored Procedures und Funktionen

SCHEMABINDING bei Views

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Mittels SCHEMABINDING kann verhindert werden, dass Objekte modifiziert werden, auf denen die Sicht basiert.
05:38

Transkript

Im Abschnitt über Early Binding habe ich Ihnen bereits schon erzählt, dass der View zwar prüft bei seiner Erstellung, ob es die entsprechenden Objekte, auf die er zugreift, auch wirklich gibt. Allerdings das es ohne Weiteres möglich ist, nachdem der View existiert, diese Objekte zu eliminieren. Um das zu unterbinden kennt der SQL-Server eine Option, die SCHEMABINDING genannt wird und die verhindert, dass verwendete Objekte, also seien es Tabellen, Schichten, Funktionen und so weiter und so fort, oder deren Spalten, genau gesagt auch, die Spalten nur, die der spezielle View verwendet, dass die in irgendeiner Form modifiziert oder gelöscht werden. Damit stelle ich sicher, dass der View bei Ausführung nicht plötzlich quasi ins Leere greift, weil es die Tabelle nicht mehr gibt, sondern kann sicher stellen, dass der View auf jeden Fall funktionieren wird soweit. Ich zeige Ihnen das mal im SQL Server Management Studio, wie das aussieht und dann spreche ich noch ein paar Wörter darüber, wo möglicherweise die Welt ein bisschen komplizierter wird an dieser Stelle. So also wieder im SQL Server Management Studio. Alt bekannte Script, ich lege eine Tabelle und entsprechend ein paar Daten an. Das kann ich mal kurz eben tun, das dauert ein paar Sekunden, so. Dann erzeuge ich einen View, allerdings noch ohne SCHEMABINDING, die Option ist hier auskommentiert. Es funktioniert natürlich ohne Weiteres. Was ich machen kann, ich kann natürlich die ganze Tabelle einfach droppen. Das heißt, die Tabelle, die der View aufbaut, ist entsprechend gelöscht und wenn ich jetzt hier versuche entsprechend darauf zuzugreifen, bekomme ich eine Fehlermeldung und das möchte ich ja möglicherweise an der Stelle vermeiden. Das heißt, ich kommentiere die VIEW SCHEMABINDING-Option ein, lasse dann das ganze Script nochmal die Datenbank anlegen, inklusive Tabelle und View. Zugriff auf dem View ist, wie gehabt, genau dass, was man auch vorher bekommen hat. Wenn ich jetzt allerdings zum Beispiel versuche die Tabelle zu löschen, bekomme ich entsprechend eine Fehlermeldung, das geht nicht. Wenn ich versuche eine einzelne Spalte zu löschen, TraceID, geht das ebenfalls nicht, weil diese Spalte hier verwendet wird. Was ich aber ohne Weiteres machen kann, ich kann zum Beispiel Spalten hinzufügen und ich kann entsprechend, wenn ich möchte, auch Spalten löschen, die in dem View nicht verwendet werden. Damit habe ich natürlich eine sichere Welt geschaffen. Ich habe damit die Möglichkeiten entsprechend die Schichten so weit sicher zu machen, dass sie nicht der Boden unter den Füßen weggezogen werden kann. Ich muss allerdings bei Updates der Datenbank, also bei Schema-Update, ein bisschen mehr aufpassen, in welche Reihenfolge ich was ändere. Ich habe keine Möglichkeit, die Tabelle quasi zu droppen und neu anzulegen, sondern ich muss es wirklich über ALTER-Statements machen, nicht auf Spalten gehen, die in den View verwendet werden. Das Gleiche gilt auch für andere Schichten und Funktionen. Es wird ein bisschen komplizierter dadurch, dass ich wissen muss, wo ich hingreife. Also ich kann keine Statements laufen lassen, die quasi die Tabelle, wie gesagt, neu anlegen, in der Einnahme, dass es dann ein, zwei neue Spalten gibt, sondern ich muss es genau differenziert hingehen und die eins, zwei Spalten, die Möglicherweise neu sind an der Stelle mit ganz dedizierten Anweisungen hinzufügen. Es ist normalerweise kein Problem, weil ich habe ja Daten in meiner Tabelle, da sollte insofern sowieso kein Drop zu Option stehen. Zum anderen kann es aber sein, dass natürlich ein View auch auf Funktionen oder auf andere Schichten zugreift. Da muss ich sehr differenziert darauf achten, in welcher Reihenfolge ich was aktualisiere, sonst bekomme ich da an der Stelle Fehlermeldungen. Also diese etwas starre Konstruktion des SCHEMABINDINGS, das sicherstellt, dass die entsprechenden Objekte auch wirklich nicht verändert werden können, kann natürlich beim Update der Datenbank möglicherweise zu Probleme oder komplexere Szenarien führen. Man muss abwiegen, was man wirklich haben möchte. Ob ich wirklich nur sichergehen möchte aufgrund der Berechtigung, dass die Objekte nicht gelöscht werden, oder ob ich wirklich hingehen möchte und per SCHEMABINDING entsprechend auf die einzelnen Objekte verweise. Ein weitere Punkt ist der, dass das SCHEMABINDING auch noch gewisse Anforderungen an mich stellt, wie das SELECT-Statement hier auszusehen hat. Wir sehen hier, dass SELECT-Statement qualifiziert jede einzelne Spalte aus, ich muss jede einzelnen Spalte einen Namen angeben, so was wie ein SELECT * ist an der Stelle nicht möglich. Wenn ich das mal ausprobiere, zum Beispiel, indem ich das schreibe, dann kann ich einfach mal die Datenbank und den View neu anlegen lassen und bekomme dann diese Fehlermeldung, die mir sagt: Die *-Syntax ist in schemagebundenen Objekten nicht zulässig. Das heißt, die Welt wird auch von der Seite ein bisschen komplexer. Ich muss in dem View wirklich genau angeben, welche Spalten ich haben möchte. Das allerdings durchaus aus guten Grund und aus Best Practices sollten Sie generell sowieso tun, weil Views, auch wenn sie nicht SCHEMABINDING sind, dass sie die Spalten angeben, doch weiß ich, dass es oft in der Praxis gerne mal Sternchen werden wird, weil es auch einfacher ist. Wenn Sie sich aber sparen wollen, das Ganze zusammen zu tippen, dann können Sie als klein Tipp folgendes machen: Sie können auf eine Tabelle oder Schicht gehen und können dann hier zum Beispiel ein SELECT-Statement sich zusammen bauen lassen und das dann per copy und paste in die Schicht hineinfügen, dann müssen Sie nicht, bei umfangreicheren Tabellen sich die Finger wund tippen.

SQL Server 2016: Triggers, Stored Procedures und Funktionen

Nutzen Sie in SQL Server Trigger, gespeicherte Prozeduren, Late Binding, Fehlerbehandlung sowie Scalar- und Tabellenwertfunktionen.

3 Std. 12 min (44 Videos)
Derzeit sind keine Feedbacks vorhanden...
 
Hersteller:
Software:
Exklusiv für Abo-Kunden
Erscheinungsdatum:08.08.2016

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!