Antwort

In SQL gibt es zwei Arten von Views:

• Normale Views (View): logische virtuelle Tabellen. Sie speichern keine Daten; die Abfrage eines VIEW generiert jedes Mal eine Unterabfrage zu den zugrunde liegenden Tabellen.
• Materialisierte Views (Materialized View): speichern physisch das Ergebnis der Abfrage in einer separaten Tabelle, die regelmäßig aktualisiert wird.

Normale Views sind nützlich, um Komplexität abzudichten, den Zugang zu vereinfachen und Daten aus mehreren Quellen zu vereinen. Sie beschleunigen keine Abfragen, da sie immer zur Laufzeit erstellt werden.

Materialisierte Views bieten Leistungsgewinne für komplexe Berichte und Analysen, bei denen es wichtig ist, nicht jedes Mal auf Aggregationen und Joins zu warten. Sie müssen manuell oder nach einem Zeitplan aktualisiert werden, damit die Daten nicht veraltet sind.

Beispiel für ein normales VIEW:

CREATE VIEW active_users AS
SELECT id, name FROM users WHERE status = 'active';

Beispiel für ein materialisiertes VIEW (PostgreSQL):

CREATE MATERIALIZED VIEW active_users_agg AS
SELECT country, COUNT(*) as cnt FROM users WHERE status = 'active' GROUP BY country;
-- Zur Aktualisierung:
REFRESH MATERIALIZED VIEW active_users_agg;

Fangfrage

Kann man Daten in einem VIEW aktualisieren und wie hängt das vom Typ des VIEWs ab?

Es wird oft fälschlicherweise angenommen, dass VIEWs in Bezug auf ihre Aktualisierbarkeit vollständig identisch mit Tabellen sind. TATSÄCHLICH:

• Normale VIEWs erlauben selten Aktualisierungen: nur wenn es keine aggregierten, gruppierten oder zusammengesetzten/berechneten Felder gibt (und auch dann keine JOINs oder Unterabfragen).
• Materialisierte VIEWs können nicht direkt aktualisiert werden – nur durch REFRESH, andernfalls entsteht eine Dateninkonsistenz.

Beispiele für reale Fehler aufgrund von Unkenntnis in diesem Bereich

---

Geschichte 1

Ein BI-Bericht wurde über ein normales VIEW mit mehreren JOINs und Aggregationen erstellt. Nach Erhöhung der Belastung stieg die Zeit zur Erstellung des Berichts auf mehrere Minuten. Ein Systemanalytiker schlug ein materialisiertes View vor, was die Zeit sofort auf Sekunden reduzierte, da die Daten in einer separaten Tabelle gespeichert wurden.

---

Geschichte 2

Ein Entwickler versuchte während der Migration auf Oracle ein UPDATE über ein normales VIEW durchzuführen, was einen Fehler auslöste: "view with group by is not updatable". Der Grund war die Verwendung von GROUP BY im View.

---

Geschichte 3

In einem Unternehmen wurden materialisierte Views nach dem Import neuer Daten vergessen zu aktualisieren, was zu Inkonsistenzen bei den Berichten zwischen verschiedenen Benutzern führte, da die Analytik mit den alten Daten aus diesem VIEW arbeitete. Danach wurde ein automatisches REFRESH nach einem Zeitplan hinzugefügt.