Eine materialisierte Sicht (Materialized View) speichert das Ergebnis einer Datenbank-Abfrage physisch auf der Platte. Während eine normale Sicht bei jedem Zugriff neu berechnet, liegt bei der materialisierten Sicht das fertige Ergebnis bereits vor — das macht Lesezugriffe auf aufwendige Auswertungen extrem schnell.
Normale Sicht oder materialisierte Sicht?
Eine klassische Sicht (View) ist nur eine gespeicherte SELECT-Abfrage: Bei jedem Zugriff führt die Datenbank die Abfrage neu aus. Eine materialisierte Sicht geht einen Schritt weiter und speichert das Abfrageergebnis dauerhaft. Wer sich die monatlichen Umsätze pro Region ansehen will, bekommt sie aus einer materialisierten Sicht sofort — ohne dass die Datenbank dafür Millionen von Einzelzeilen erneut durchrechnen muss.
Vorteile
- Geschwindigkeit: Aufwendige Aggregationen und Joins über große Tabellen sind vorberechnet.
- Entlastung: Die Quelltabelle wird bei Auswertungen nicht ständig neu gelesen — gut für OLTP-Systeme.
- Query Rewrite: Der Query-Optimierer kann passende Anfragen automatisch auf die materialisierte Sicht umleiten.
Nachteile und Refresh
Materialisierte Sichten sind nicht automatisch aktuell: Ändern sich die Quelldaten, muss die Sicht aufgefrischt werden (REFRESH MATERIALIZED VIEW). Es gibt zwei Refresh-Formen:
- Voll-Refresh (Complete): Die Sicht wird komplett neu berechnet — einfach, aber teuer bei großen Datenmengen.
- Inkrementeller Refresh (Fast): Nur die seit dem letzten Lauf geänderten Zeilen werden nachgeführt (oft über ein MV-Log).
PostgreSQL unterstützt zusätzlich REFRESH MATERIALIZED VIEW CONCURRENTLY: Die Sicht bleibt während der Aktualisierung lesbar, verlangt dafür aber einen Unique-Index. Auch Oracle und SQL Server (dort als indexierte Sicht) bieten materialisierte Sichten.
Typische Einsatzgebiete
Materialisierte Sichten glänzen im Data Warehouse und im Reporting: tägliche Umsatzauswertungen, Kennzahlen-Dashboards oder die Vorbereitung von Daten für analytische Datenbanken. Wer den Ladezustand und die Aktualität im Blick behält, bekommt damit die Vorteile eines Caches direkt in der Datenbank.
Verwandte Grundlagen: Query-Optimierung, Ausführungsplan (EXPLAIN), Datenbank-Indizes, Data Warehouse, ETL.