SQL Server 2016: Triggers, Stored Procedures und Funktionen

Sichten anlegen und modifizieren

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Sie erhalten eine Definition von Sichten, erfahren, worauf Sie bei Sichten achten müssen und legen gleich los: Legen Sie Ihre erste Sicht an!
07:36

Transkript

Beginnen wir mit Schichten. Schichten sind nicht anderes, als auf dem Server gespeicherte Abfragen, die von Client per Name aufgerufen werden können. Das hat einige Vorteile. Unter anderem muss sich der Client nicht mit der Definition der Schicht, also der Abfrage in der Schicht, beschäftigen. Die kann durchaus etwas umfangreicher sein und trotzdem greift der Client nur kurz und kompakt über den Namen drauf zu. Der Vorteil vom Server aus ist, dass er die Abfrage bereits kennt, das heißt, es ist keine ad hoc Abfrage. Das kann sich durchaus positiv auf die Performance auswirken. Ich kann serverseitig Berechtigungen auf Schichten vergeben, das macht durchaus auch Sinn. Und ich habe den Vorteil, dass ich entsprechend Schichten zentral verwalten kann, das heißt, wenn sich irgendetwas ändert, muss ich nicht alle Clients oder alle Programme, die darauf zugreifen, anpassen, sondern ich kann die Korrektur oder Erweiterung schlicht in der Schicht durchführen. Ich habe hier das Wichtigste in Kürze zusammengestellt, was eine Schicht betrifft. Und zwar besteht eine Schicht immer aus einer SELECT-Anweisung, das heißt, Sie können kein INSERT, DELETE oder UPDATE unterbringen. Alle Spalten einer Schicht müssen einen eindeutigen Namen haben. Bei ad hoc Abfragen ist das nicht so, da können Sie Spalten haben, die keinen Namen haben, oder Sie können einfach einen Namen mehrfach vergeben und das ist hier bei Schichten nicht erlaubt. Schichten verwenden Early Binding, das zeige ich Ihnen gleich in einem Beispiel. Das bedeutet, zu dem Zeitpunkt, wo Sie die Schicht anlegen, müssen alle Objekte, die die Schicht verwendet, also Funktionen, Tabellen, andere Schichten, in der Tat vorhanden sein. Damit können Sie zum Beispiel innerhalb von Schichten keine temporären Tabellen oder Ähnliches verwenden. Dann sollten Schichten keine Sortierung, also kein ORDER BY beinhalten. Es ist zwar über Tricks möglich, aber nicht besonders geschickt, was die Performance betrifft. Die Sortierung ist das Letzte, was der SQL-Server bei einer Abfrage durchführt und wenn Sie eine Schicht haben, die die Daten auf einer Art sortiert, und Sie später selber bei dem Zugriff auf die Schicht wiederum in einer anderen Art sortieren wollen, kann es sein, dass die Daten mehrfach sortiert werden müssen, das bedeutet Aufwand. Letztendlich haben Sie sowieso nur eine Sortierung, insofern sollten Sie eigentlich auf Sortierungen in Views verzichten. Dann können Schichten verschlüsselt werden. Das werde ich Ihnen auch zeigen, es gibt eine Encryption-Möglichkeit für Schichten. Sie können dann zwar die Schicht benutzen, aber Sie haben keine Chance auf den Quelltext der Schicht heranzukommen. Und Schichten können SCHEMABINDING verwenden. Das bedeutet, die Schicht kann so angelegt werden, dass sie die Objekte, auf die sie zugreift, auch hier wieder Tabellen, Schichten oder Funktionen, blockiert, diese können dann nicht geändert oder gelöscht werden solange entsprechend diese Schicht gibt, die das SCHEMABINDING verwendet. Der Vorteil liegt auf der Hand, ich kann sicherstellen, dass ein View durchaus immer funktioniert. Ansonsten hätte ich nämlich die Option eine Schicht anzulegen und die darunter liegende Tabelle beispielsweise zu löschen und das würde erst bei einem Aufruf auffallen, insofern kann ich das mit SCHEMABINDING an der Stelle unterbinden. Allerdings habe ich da den Nachteil bei Updates, dass es teilweise schwieriger ist die Datenbank zu aktualisieren, also nicht die Daten, sondern das Schema der Datenbank. Da muss ich wirklich genau die richtige Reihenfolge einhalten, sonst stolpere ich nämlich selber von einer Einschränkung in die nächste, weil ein Objekt das andere im SCHEMABINDING blockiert. Ich habe nie so etwas wie eine Zirkulation, also es gibt eine richtige Reihenfolge, aber ich muss die einbehalten. Dann geht es auf ins SQL Server Management Studio und da zeige ich Ihnen mal die grundlegenden Züge. Im SQL Server Management Studio habe ich diese Script geladen. Ich lasse zuerst diesen Block laufen, der mir die Datenbank, die ich benötige, anlegt. An View erzeuge ich mit der CREATE VEIW-Anweisung. Danach kommt der Name, inklusive Schema an den Fall, AS als Schlüsselwort und dann den SELECT-Statement, was ich in diesem View ablegen möchte. Das heißt, ich kann das hier einmal testweise in der Tat so ausführen, es ist eine ad hoc Anfrage für den SQL-Server und es liefert mir hier in dem Fall alle Datenbanken. Wenn ich das zusammen mit dem CREATE VIEW ausführe, dann habe ich den View angelegt. Ich kann hier auf dem Objekt Explorer mal nachschauen, die Datenbank sollte da sein, in der Datenbank gibt es Views oder Schichten und hier habe ich entsprechend diese Schicht und ich kann hier hingehen und sagen Select Top und ich bekomme hier dann entsprechend die Ausgabe. Die Benutzung von Views ist ziemlich identisch mit der für Tabellen, das heißt, ich kann immer hingehen und sagen SELECT * FROM und kann dann den View angehen, das ist das, was ich gerade über die Oberfläche gemacht habe und ich bekomme auch das gleiche Ergebnis. Interessant ist, Sie können auch Daten durch Views ändern. Da würde ich Ihnen aber definitiv von abraten. Es ist in der Regel nicht das, was man an Änderungen haben möchte, insofern sollten Sie sich als Regel merken, dass Sichten wirklich das sind, was sie von Namen her schon ausdrücken, nämlich einfach nur Schichten auf Daten. Auch wenn der SQL-Server Änderungen zulässt, sollten Sie extrem vorsichtig sein, ob Sie das wirklich wollen und doppeltesten, ob das wirklich rauskommt in den darunter liegende Tabellen, wo entsprechend Sie davon ausgehen, dass es auch wirklich das Ergebnis sein sollte. Insofern gehe ich jetzt erstmal davon aus, dass ich die Views auch, bis auf spätere Beispiele wirklich nur als Quelle für SELECT-Statements verwende. Dann kann ich mit ALTER VIEW eine bestehende Schicht verändern. Ich habe damit die Möglichkeit zum Beispiel hinzugehen und die Definition umzukehren. Sie sehen hier, ich habe das Prädikat gleich geändert. Wenn ich das ausführe, dann quittiert er mir das auch mit einem positiven Ergebnis. Ich kann jetzt hier ein SELECT auf die View machen und die ist dann entsprechend leer, weil es keine Snapshots hier auf diesem Server gibt. Damit sehen Sie, CREATE liegt an, ALTER ändert und zum Schluss DROP löscht, wie bei allen anderen Objekten auf diesem Server auch. Das heißt das gleiche Schema, was sie auch mit Prozeduren, mit Funktionen, mit Tabellen haben, immer CREATE, ALTER, DROP. DROP geschieht einfach mit DROP VIEW. Allerdings DROP VIEW löst einen Fehler aus für den Fall, dass das Element nicht gibt, also dass das View gar nicht vorhanden ist auf dem Server, und deswegen müssen Sie, wenn Sie nicht 2016 schon einsetzen, immer davor sicherstellen, ob das Objekt wirklich vorhanden ist. Das können Sie machen mit Einsatz der OBJECT_ID-Funktion. Die liefert mir entsprechend nur eine ID und nicht NULL, wenn es den View gibt. Das heißt, ich übergebe ihn hier den voll qualifizierten Namen des Views zusätzlich mit einem V, das sagt diese OBJECT_ID-Funktion, dass ich einen View suche, sonst würde er nur nach dem Namen suchen der SQL-Server und es könnte theoretisch sein, dass ich auch ein anderes Objekt habe, was genau so heißt, möglich wäre es, und er würde dann mir die ID zurückgeben, diese Abfrage würde vermuten, dass den View gäbe und wenn ich dann hingehe und entsprechend DROP VIEW ausführen würde, begebe es einen Fehler. Das heißt, hier muss ich wirklich noch den umfangreichen Weg beschreiten, aber dafür ist das auf jeden Fall eine sichere Anweisung und Sie sehen auf der View ist verschwunden. Ab SQL-Server 2016 können Sie es ein bisschen kompakter gestalten. Sie können sagen DROP IF EXISTS. Das kann man bei ziemlich allen Objekten dann machen. Ich habe damit die Möglichkeit das kompakter zu gestalten, das heißt, DROP wird an der Stelle nur ausgeführt, wenn es das Objekt in der Tat wirklich auch gegeben hat, ansonsten macht er schlicht und ergreifend gar nichts.

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!