MySQL - Views

[GELight]

Hallo alle zusammen,

Ich bin derzeit dabei mich mal in das Thema Views einzulesen und so langsam geht mir auch ein Licht auf... jedoch habe ich ein paar kurze grundlegende Fragen zur Arbeit mit Views und wie das Ganze im Hintergrund so abläuft.

zur Frage 1: Wird ein einmal erstellter View auf dem Server im Speicher gehalten oder wird dieser auch bei jeder Aktualisierung erneut aufgebaut? ( jedes mal neu würde für mich keinen Sinn ergeben aber ich frage dennoch )

zur Frage 2: Wie funktioniert das allgemein im Hintergrund mit diesen Views?
Werden diese von der DB automatisch immer wieder aktualisiert, sobald sich an den Basistabellen etwas ändert oder muss man das anstoßen?

und somit auch gleich zu Frage 3: Wenn ich in einem View ein UPDATE durchführe.... wird dementsprechend auch die Haupttabelle irgendwie mit aktualisiert?

Ich will erstmal noch ein paar Grundlagen verstehen, bevor ich hier unnütz viele Fragen stelle, die ich mir evtl. danach auch selbst beantworten kann.

Dank euch aber für Antworten...

Gruß Mario

[AmicaNoctis]

Hallo,

ein View in MySQL kannst du dir als eine Art gespeicherte Abfrage vorstellen. Das dürfte schon einige Fragen klären: Sie sind immer so aktuell wie die dahinterliegende(n) Tabelle(n) und Updates (auch Inserts oder Deletes) funktionieren sowieso nicht mit Views (es sei denn, es basiert nur auf einer einzigen Tabelle, dann wird diese direkt modifiziert).

Gruß,

Amica

[GELight]

Views

Hi AmicaNoctis,

Hey.... super Antwort, danke. Dann legt die DB diese "fertige" Anfrage also irgendwo ab bzw. hält diese im Speicher oder so ähnlich oder?
Was macht es denn so viel schneller Daten aus einem View zu lesen oder der echten Tabelle?

Daher meine Frage ob Filesystem oder Speicher...

Gruß Mario...

[AmicaNoctis]

Aus einem View wird imho normalerweise nicht schneller gelesen als aus einer Tabelle, es sei denn, das View besitzt eine Where-Klausel, die nur einen Bruchteil der Datensätze selektiert, dann ist es natürlich schneller als eine Abfrage auf der Basistabelle ohne Where-Klausel.

[goth]

Insbesondere in der Implementierung der MySQL bringen Views ziemlich wenig ... insbesondere vom Gesichtspunkt der Performance. Gerade Views die keine WHERE Bedingung enthalten und deren Ergebnis in der eigentlichen Abfrage eingegrenzt werden sollen zeichnen sich durch eine extrem verschnarchte Performance aus.

Leider beherrscht MySQL noch keine "materialized views" wie sie richtige RDBMS Systeme implementieren.

[GELight]

Views

Hm... das klingt als würde es mir nur bedingt Geschwindigkeitsvorteile bringen, wenn ich dich (goth) richtig verstehe. Also macht ein View in MySQL eigentlich nur wirklich Sinn, wenn dessen SELECT durch eine WHERE Klausel aus der org. Tabelle auch wieder nur einen Teil der Daten holt, damit der wiederum spätere Zugriff auf die Daten im View auch Geschwindigkeitsvorteile durch einfach weniger Datensätze bringt, die durchlaufen werden müssen.

Sehe ich das richtig?

Gruß Mario

[onemorenerd]

Ein View macht auch dann Sinn, wenn man dem Client nicht alle Daten zeigen will.
Der Client bekommt dann das Recht, den View zu benutzen, aber nicht das Recht direkt mit der Tabelle zu arbeiten.
Darf er bestimmte Spalten nicht sehen, werden die im SELECT des Views weg gelassen.
Darf er bestimmte Zeilen nicht sehen, werden die durch das WHERE des Views ausgeblendet.
Beides kann natürlich auch kombiniert werden.

[GELight]

Views

Ich denke, ich werde mich mal an ein paar praktischen Übungen und Tests versuchen. Werde schon einen sinnvollen Weg finden, solche Views verwenden zu können. Ist auch und gerade eine philosophische Sache. Muss erst einmal etwas verinnerlichen denke ich...

Aber Ihr habt mir schon super geholfen. Danke nochmal...

Eine letzte Frage noch: "materialized views" - was ist der grobe Unterschied?
Jetzt hast mich neugierig gemacht

Gruß Mario

[goth]

@GELight: Wie es onemorenerd erwähnt hat gibt es verschiedene Gründe einen View zu verwenden ... die Performance ist auf jeden Fall keiner. Da könnte man schon eher darüber nachdenken mit Hilfe von Triggern sowas wie Snapshots zu "emulieren" ... also eine Tabelle erstellen, deren Daten bei jeder Änderung in den Grundtabellen via ON UPDATE, ON INSERT bzw. ON DELETE Trigger angepasst werden.

Alles in allem hat zumindest meine Erfahrung mit MySQL, ORACLE, SQL-Server und INFORMIX gezeigt, das die MySQL Views der allergrößte Murks sind (zumindest in Hinblick auf die Performance) alleine schon aus dem Grunde, das allem Anschein nach die Indizes der Zugrundliegenden Tabellen zumindest nicht hinreichend (wenn überhaupt) genutzt werden ... EXPLAIN lasst sowas zumindest vermuten ...

[goth]

Thema Materialized Views:

Sicht (Datenbank) ? Wikipedia

Dort ganz unten.

[onemorenerd]

Als "materialized view" bezeichnet man einen View, den das DBMS sozusagen im Voraus berechnet. Dazu wird eine versteckte Tabelle benutzt, deren Inhalt bei jeder Änderung der dem View zugrunde liegenden Tabelle neu bestimmt wird.
Benutzt man den View, wird der nicht als Query auf der zugrunde liegenden Tabelle ausgeführt sondern nur die zusätzlichen Einschränkungen auf die versteckte Tabelle angewendet und so das Resultset erzeugt.

Klingt kompliziert, ist aber ganz einfach. Mal ein Beispiel ...

die Tabelle: table(id, foo, bar) { (1, 'a', 'b'), (2, 'x', NULL), (3, 'y', NULL) }
der View: "CREATE VIEW myView AS SELECT id, foo FROM table WHERE bar IS NULL";

Der View wird beim Anlegen materialisiert, d.h. es wird eine weitere Tabelle angelegt
_myView(id, foo) { (2, 'x'), (3, 'y') }

Nach jeder Änderung an table wird myView ausgeführt um _myView aktuell zu halten.

Stellt man nun eine Anfrage "SELECT foo FROM myView WHERE id = 2", wird das Ergebnis aus _myView erzeugt. Das geht schneller* als bei nicht-materialisierten Views, weil _myView weniger* Daten enthält als table.


*) Das trifft immer zu, denn der View enthält immer weniger Daten (Spalten und/oder Zeilen) als die Originaltabelle. Sollte das mal nicht so sein, weil der View gegenüber der Originaltabelle überhaupt keine Einschränkungen enthält, merkt das ein gutes DBMS und materialisert diesen View nicht.

[goth]

Das Problem der MySQL ist aber wie gesagt eher, dass die Indizes der Grundtabellen nicht verwendet werden (können) wenn das Ergebnis einer Abfrage eingegrenzt werden soll ...

[medium22]

Mal ganz am Rande bemerkt.. Ein (für mich) sehr interessantes Thema weil ich mich auch schon mit Views versucht habe, aber meist den Sinn darin nicht sah. Aber so wie ihr das hier erklärt, geht mir doch glatt ein Lichtlein auf wie man die (auch in MySQL) viel effektiver nutzen könnte - jedenfalls effektiver als bisher von mir angenommen.

Danke dafür!

[goth]

Mal ganz am Rande bemerkt.. Ein (für mich) sehr interessantes Thema weil ich mich auch schon mit Views versucht habe, aber meist den Sinn darin nicht sah. Aber so wie ihr das hier erklärt, geht mir doch glatt ein Lichtlein auf wie man die (auch in MySQL) viel effektiver nutzen könnte - jedenfalls effektiver als bisher von mir angenommen.

Danke dafür!

Schön ... und läßt Du uns alle schöpfen aus dem Füllhorn deiner Weisheit ... ?!

[medium22]

Das waren und sind bisher rein theoretische Gedankengäng, also nichts was ich zeigen/beschreiben könnte - zumal das Projekt für welches das ggf. geeignet werde nur in der Theorie besteht.. Könnte also nicht mal zwischen normalem Query und View-Query vergleichen..