Hi.
Kann jemand von euch DB-Profis mir kurz und verständlich erklären, was man unter einer ‚View‘ zu verstehen hat??
Danke
Markuss
Hi.
Kann jemand von euch DB-Profis mir kurz und verständlich erklären, was man unter einer ‚View‘ zu verstehen hat??
Danke
Markuss
Hi.
Kann jemand von euch DB-Profis mir kurz und verständlich
erklären, was man unter einer ‚View‘ zu verstehen hat??
Du kannst SELECT-Abfragen in der Datenbank als View Speichern. Der View sieht für deine Applikation wie ein Tabelle aus, d.h. statt das urspüngliche SQL-Statement abzusetzen, rufst du dann „SELECT * FROM mein_view“ auf.
Sinnvoll ist das ganze, wenn du komplexe SELECT-Statements verwendest, die aus mehreren Zeilen bestehen und recht unübersichtlich geworden sind.
Bei Oracle kannst du beispielsweise mit
CREATE VIEW mein_view
SELECT * FROM Kunden WHERE NOT VIP_KUNDE AND Umsatz > 1000
einen View erstellen, den du mit
SELECT * FROM mein_view
abfragen kannst. Die meisten Datenbanken unterstützen Views, bei MS Access heissen sie „Abfragen“.
Gruß Markus
wortfuchs hat vollinhaltlich recht. trotzdem eine kleine ergänzung.
views werden auch gerne verwendet, um zugriffe besser steuern zu können. beispiel: applikation 1 verwendet tabelle a, die neben dem namen der mitarbeiter auch das gehalt desselben enthält. applikation 2 soll auf die selben namensdaten zugreifen, allerdings geht die dortigen benutzer das gehalt nix an. natürlich kann man einfach in der applikation die daten ausblenden (=erst gar nicht selektieren). aber vielleicht soll ja bereits der entwickler nicht auf das gehalt zugreifen dürfen. man erstellt also eine view, die alle spalten der tabelle a selektiert allerdings ohne die gehaltsspalte. applikation 2 bekommt dann ausschließlich select-rechte auf die view und nicht auf die tabelle a. mit der view kann genauso gearbeitet werden wie mit der tabelle - nur dass die gehaltsspalte einfach nicht sichtbar ist.
views eignen sich auch dazu, zugriffe auf entferne tabellen transparent zu machen. beispiel: applikation 1 benötigt tabelle a auf server x und tabelle b auf server y. natürlich kann die applikation jetzt „select * from a@x“ und „select * from b@y“ absetzen. dann muss die applikation aber genau wissen, wie die server heissen. beim testen muss man dann ständig herumbasteln, damit man nicht unabsichtlich in die produktionstabellen herumpfuscht. abhilfe: eine view c (create view c as select * from a@x) und analog eine view d. die applikation braucht nur mehr die views c und d kennen. in der testumgebung zeigen die views auf tabellen eines entwicklungsservers. in der produktionsumgebung eben auf die produktionstabellen. die applikation braucht davon nichts wissen.
ab der version 8 von oracle kann man in der from-klausel ein select-statement angeben - man kann damit eine tabelle mit dem ergebnis eines select-statements joinen. einige abfragen (vor allem komplexere reports) lassen sich nur so lösen. mit oracle 7 musste man sich für die „innere“ abfrage eine view definieren um dann die tabelle mit der view joinen zu können.
es gibt sicher noch weitere beispiele für die verwendung von views nur fallen mir jetzt keine vernünftigen mehr ein… ;->
erwin
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]