Wenn man mittel Java oder PHP oder einer Programmiersprache deiner Wahl auf ein RDBMS zugreift, dann kann man Code erstellen, der sich ohne Umwege der Tabellen bedient. Man kennt den Namen der Tabellen und ihre Spaltenbezeichnungen. Dann ist fix eine Abfrage gecodet und – schwupps – erscheint das Ergebnis in der Anwendung. So weit, so gut, so einfach.
Kompliziert wird es, wenn Tabellen sich ändern – beispielsweise wegen Kundenanpassungen. Für den bereits bestehenden Code ist das nicht gut, denn der “wettet” ja auf eine ganz bestimmte Struktur. Beim Ändern der Tabelle müßte man also darauf achten, bestehenden Code nicht zu zerbrechen – was für eine Qual! Ich müßte den gesamten Code abklappern … gar nicht gut, das dauert viel zu lange und Chef sitzt mir im Nacken. Was tun?
Eine Option ist, den Quelltext so zu organisieren, dass mir das Abklappern leicht fällt. Aber das ist ein anderes Thema. Hier und jetzt möchte ich die Seite des RDBMS beleuchten. Kann mir das helfen? Natürlich kann es das.
Die mir bekannten RDBMS erlauben es, Views zu erstellen. Ein View kann man sich als benannte und im RDBMS gespeicherte Abfrage vorstellen. Das ist eine hilfreiche Option, dem Kind einen Namen geben zu können – hilfreich für das Verständnis, das Debuggen. Und man kann die Daten so bekommen, wie man sie braucht: Man kann weglassen, Spalten umbenennen, mit join arbeiten usw. – eben all die Techniken nutzen, die ein select bietet. Der View “kennt” die benötigten Tabellennamen, aber der Nutzer des Views braucht die beteiligten Tabellennamen und -strukturen nicht zu kennen. Der Nutzer des Views kennt – nur den View. Wie der View zu seinem Ergebnis kommt, ist dem View-Abfrager gleichgültig. In der Programmierung nennen wir dieses Prinzip “Kapselung”.
Auf der Seite der Client-Programmierung macht es keinen Unterschied, ob ich eine Tabelle abfrage oder einen View. Deswegen bietet das Erstellen von Views die Möglichkeit, eine stabile Schnittstelle aufzubauen. Feine Sache, weil der zugreifende Code nicht zerbrechen wird, wenn ich eine Tabelle ändere, die jenseits der Schnittstelle liegt.
Eitel Sonnenschein? Fast. Woher weiss ich, dass eine Tabellenänderung nicht Views kaputt macht? Hier hilft mir eine Automatisierung: Ich habe ein Script, das alle Views löscht. Und ich habe ein Script, das alle Views aufbaut. Wenn die beiden Scripte erfolgreich abgearbeitet werden können, dann ist’s in Ordnung. Wenn nicht, dann kann ich anhand der Fehlermeldung beim Anlegen genau sehen, was und wo es schiefgeht.
Offene Frage: Ist einfügen in und löschen aus Views möglich? Mit Oracle’s RDBMS schwant mir, dass es möglich ist, wenn der View “key preserved” ist. Mssql löscht einfach – und unter Umständen ist man überrascht, was da gelöscht wird und was nicht :-/
Offene Frage: Gibt es Views mit Parametern? Das wäre praktisch …