View vs. Materialized View: die Unterschiede, die zaehlen

1. Was eine View wirklich ist: eine gespeicherte Query

Eine View ist im Kern nichts anderes als eine benannte, gespeicherte SQL-Abfrage. Wird eine View in einer SELECT-Anweisung referenziert, ersetzt die Datenbank den View-Namen intern durch die hinterlegte Query und fuehrt das Ganze als eine kombinierte Anweisung aus. Es gibt keine eigenen physisch gespeicherten Daten hinter einer View, lediglich die Definition der Abfrage selbst wird im Systemkatalog gespeichert. Das erklaert das zentrale Merkmal jeder View: Sie liefert bei jedem Zugriff garantiert aktuelle Daten, weil die zugrunde liegende Abfrage jedes Mal frisch gegen die Basistabellen ausgefuehrt wird.

Diese Eigenschaft macht eine View zu einem reinen Abstraktionswerkzeug. Komplexe JOINs, Aggregationen oder Filterbedingungen lassen sich hinter einem einfachen, sprechenden Namen verstecken, ohne dass die Anwendung die zugrunde liegende Komplexitaet kennen muss. Zugriffsrechte lassen sich ueber Views granularer steuern als ueber Tabellen, indem etwa nur bestimmte Spalten einer sensiblen Tabelle in einer View exponiert werden, waehrend die Basistabelle selbst fuer den Nutzer unerreichbar bleibt.

Der Nachteil ergibt sich direkt aus dieser Funktionsweise: Da eine View keine eigenen Daten speichert, kostet jeder Zugriff die volle Ausfuehrungszeit der zugrunde liegenden Abfrage. Eine View ueber eine komplexe Aggregation mit mehreren JOINs ueber grosse Tabellen ist bei jedem einzelnen SELECT genauso teuer wie die Original-Query selbst, es findet keinerlei Zwischenspeicherung des Ergebnisses statt.

-- A standard view: stores the query definition, not the result
CREATE VIEW active_customer_summary AS
SELECT
  c.id,
  c.name,
  COUNT(o.id) AS order_count,
  SUM(o.total) AS lifetime_value
FROM customers c
JOIN orders o ON o.customer_id = c.id
WHERE c.status = 'active'
GROUP BY c.id, c.name;

-- Every query against the view re-executes the underlying SQL
SELECT * FROM active_customer_summary WHERE lifetime_value > 1000;
-- Always reflects the current state of customers and orders,
-- but pays the full cost of the JOIN and aggregation on every call

2. Was eine Materialized View wirklich ist: ein gespeichertes Ergebnis

Eine Materialized View kehrt das Prinzip einer normalen View um: Statt nur die Query zu speichern, wird das Ergebnis der Query physisch auf der Festplatte abgelegt, aehnlich wie bei einer regulaeren Tabelle. Ein Zugriff auf eine Materialized View liest ausschliesslich diese gespeicherten Ergebniszeilen, ohne die zugrunde liegende Abfrage erneut auszufuehren. Das macht Lesezugriffe auf eine Materialized View so schnell wie Lesezugriffe auf eine normale Tabelle, unabhaengig davon, wie komplex die urspruengliche Abfrage war.

Der Preis dieser Geschwindigkeit ist Aktualitaet. Sobald sich die Basistabellen aendern, weiss die Materialized View davon zunaechst nichts, ihre gespeicherten Daten bleiben auf dem Stand des letzten Refresh eingefroren. Dieses Verhalten wird oft als Staleness bezeichnet, der zeitliche Abstand zwischen dem tatsaechlichen Zustand der Basisdaten und dem Zustand, den die Materialized View widerspiegelt. Je nach Anwendungsfall ist diese Verzoegerung vollkommen unproblematisch oder ein Ausschlusskriterium.

PostgreSQL unterstuetzt Materialized Views nativ ueber CREATE MATERIALIZED VIEW. Oracle und SQL Server bieten aehnliche Konzepte unter den Namen Materialized View beziehungsweise Indexed View, wobei SQL Servers Indexed View technisch eine Sonderform ist, die automatisch statt manuell aktualisiert wird. MySQL kennt bis heute keine native Materialized View, das Konzept wird dort typischerweise ueber eine regulaere Tabelle nachgebildet, die per Event Scheduler oder Trigger periodisch neu befuellt wird.

-- PostgreSQL: materialized view stores the result physically on disk
CREATE MATERIALIZED VIEW active_customer_summary_mv AS
SELECT
  c.id,
  c.name,
  COUNT(o.id) AS order_count,
  SUM(o.total) AS lifetime_value
FROM customers c
JOIN orders o ON o.customer_id = c.id
WHERE c.status = 'active'
GROUP BY c.id, c.name;

-- Reading from a materialized view is as fast as reading a plain table
SELECT * FROM active_customer_summary_mv WHERE lifetime_value > 1000;

-- MySQL has no native materialized view: emulate it with a real table
CREATE TABLE active_customer_summary_table (
  id INT PRIMARY KEY,
  name VARCHAR(255),
  order_count INT,
  lifetime_value DECIMAL(12,2)
);
-- Populated on a schedule via an EVENT or an application job

3. Performance-Unterschiede bei Lesezugriffen

Der Performance-Unterschied zwischen einer View und einer Materialized View wird umso deutlicher, je komplexer und teurer die zugrunde liegende Abfrage ist. Bei einer einfachen View, die lediglich einige Spalten filtert oder umbenennt, ist der Overhead gegenueber einer direkten Tabellenabfrage vernachlaessigbar, weil der Query-Optimizer die View-Definition meist problemlos in die aeussere Abfrage einbetten und optimieren kann. Bei einer View mit mehreren JOINs, Unteraggregationen oder Fensterfunktionen ueber grosse Datenmengen kann jeder einzelne Zugriff dagegen mehrere Sekunden oder laenger dauern, weil die komplette Berechnung bei jedem Aufruf von Neuem geschieht.

Eine Materialized View verschiebt diese Rechenkosten vollstaendig vom Lesezeitpunkt zum Refresh-Zeitpunkt. Der teure JOIN oder die teure Aggregation wird nur beim Refresh einmal berechnet, jeder nachfolgende Lesezugriff liest lediglich die bereits fertigen Zeilen. Bei Dashboards, Reports oder Analytics-Anwendungen, die dieselbe komplexe Abfrage hunderte Male pro Stunde ausfuehren, kann dieser Unterschied den Faktor zwischen Sekunden und Millisekunden pro Anfrage ausmachen.

4. Aktualitaet vs. Staleness: das Kernproblem

Die Wahl zwischen View und Materialized View ist im Kern eine Entscheidung zwischen Konsistenz und Geschwindigkeit. Eine normale View garantiert, dass jede Abfrage exakt den aktuellen Zustand der Basistabellen widerspiegelt, weil sie bei jedem Aufruf frisch berechnet wird. Diese Eigenschaft ist unverzichtbar bei Anwendungsfaellen, in denen veraltete Daten zu falschen Entscheidungen fuehren koennten, etwa bei einem aktuellen Kontostand, einem Lagerbestand kurz vor dem Checkout oder einer Preisberechnung in Echtzeit.

Eine Materialized View akzeptiert bewusst einen gewissen Grad an Staleness zugunsten von Geschwindigkeit. Fuer viele Analytics- und Reporting-Anwendungsfaelle ist ein Datenstand, der wenige Minuten oder sogar Stunden alt ist, vollkommen ausreichend, weil die Nutzer ohnehin keine Sekunden-genaue Aktualitaet erwarten. Der entscheidende Punkt bei der Entscheidung ist also nicht, welche Technik grundsaetzlich besser ist, sondern welchen maximalen Datenverzug der konkrete Anwendungsfall toleriert, ohne dass Entscheidungen auf Basis veralteter Zahlen getroffen werden.

5. Refresh-Strategien fuer Materialized Views

Der Refresh-Mechanismus ist der zentrale Betriebsaspekt jeder Materialized View. PostgreSQL bietet zwei Varianten: REFRESH MATERIALIZED VIEW, das die gesamte View sperrt und waehrend der Neuberechnung fuer Lesezugriffe blockiert, und REFRESH MATERIALIZED VIEW CONCURRENTLY, das parallel weiterhin Lesezugriffe auf die alten Daten erlaubt und erst nach Fertigstellung atomar umschaltet. Letzteres benoetigt zwingend einen eindeutigen Index auf der Materialized View, ist dafuer aber die praxistaugliche Wahl fuer produktive Systeme, bei denen ein blockierender Refresh nicht akzeptabel ist.

Neben dem vollstaendigen Refresh, der die kompletten Daten neu berechnet, bieten manche Datenbanksysteme inkrementelle Refresh-Mechanismen, die nur die tatsaechlich geaenderten Zeilen aktualisieren. Diese Mechanismen sind komplexer zu implementieren und nicht ueberall verfuegbar, reduzieren aber bei grossen Materialized Views mit haeufigen, kleinen Aenderungen die Refresh-Zeit drastisch gegenueber einer kompletten Neuberechnung. Die Refresh-Haeufigkeit selbst wird meist ueber einen periodischen Job, einen Scheduler oder einen Trigger auf relevante Basistabellenaenderungen gesteuert.

Bei der Wahl der Refresh-Strategie muss abgewogen werden, wie stark die Refresh-Last selbst das System belastet. Ein staendiger Refresh bei jeder kleinsten Aenderung an der Basistabelle naehert sich in der Praxis dem Verhalten einer normalen View an und verliert den Geschwindigkeitsvorteil, waehrend ein zu seltener Refresh die Staleness ueber ein akzeptables Mass hinaus wachsen laesst.

-- PostgreSQL: blocking refresh (locks the materialized view during rebuild)
REFRESH MATERIALIZED VIEW active_customer_summary_mv;

-- PostgreSQL: non-blocking refresh, requires a unique index
CREATE UNIQUE INDEX idx_acs_mv_id ON active_customer_summary_mv (id);
REFRESH MATERIALIZED VIEW CONCURRENTLY active_customer_summary_mv;

-- Scheduled refresh via a periodic job (e.g. cron, pg_cron, or an EVENT in MySQL)
-- pg_cron example: refresh every 15 minutes
-- SELECT cron.schedule('*/15 * * * *', 'REFRESH MATERIALIZED VIEW CONCURRENTLY active_customer_summary_mv');

-- MySQL: rebuild the emulated materialized view table inside an EVENT
CREATE EVENT refresh_active_customer_summary
ON SCHEDULE EVERY 15 MINUTE
DO
  REPLACE INTO active_customer_summary_table
  SELECT c.id, c.name, COUNT(o.id), SUM(o.total)
  FROM customers c
  JOIN orders o ON o.customer_id = c.id
  WHERE c.status = 'active'
  GROUP BY c.id, c.name;

6. Speicherverbrauch und Storage-Overhead

Eine normale View belegt praktisch keinen Speicherplatz jenseits der Query-Definition selbst, ein paar hundert Byte im Systemkatalog. Eine Materialized View hingegen belegt exakt so viel physischen Speicherplatz wie eine reguläre Tabelle mit derselben Zeilen- und Spaltenanzahl, plus den Speicherplatz fuer eventuelle Indizes darauf. Bei einer Materialized View ueber eine grosse Aggregation kann diese Speichermenge trotzdem deutlich geringer sein als die der Basistabellen, weil Aggregationen die Zeilenanzahl typischerweise stark reduzieren.

Dieser Speicherverbrauch ist kein Nebeneffekt, sondern der eigentliche Kompromiss: Man tauscht Speicherplatz und Refresh-Rechenzeit gegen Lesezeit ein. Bei Systemen mit knappem Speicherbudget oder vielen unterschiedlichen Materialized Views summiert sich dieser Speicherbedarf, und es lohnt sich, regelmaessig zu pruefen, ob eine Materialized View tatsaechlich noch genutzt wird, bevor sie unnoetig Speicherplatz und Refresh-Zyklen bindet.

7. Indexierung von Views und Materialized Views

Auf einer normalen View koennen in den meisten Datenbanksystemen keine eigenen Indizes angelegt werden, weil es keine physischen Daten gibt, auf die sich ein Index beziehen koennte. Stattdessen profitiert eine View ausschliesslich von Indizes auf den zugrunde liegenden Basistabellen, die der Optimizer beim Einbetten der View-Definition in die aeussere Abfrage beruecksichtigt. Eine Ausnahme bildet SQL Servers Indexed View, die als Sonderform tatsaechlich physisch materialisiert und indiziert wird, dabei aber automatisch statt manuell mit den Basistabellen synchron gehalten wird.

Eine Materialized View hingegen ist eine eigenstaendige physische Struktur und kann wie jede Tabelle mit eigenen Indizes versehen werden. In der Praxis ist ein Index auf den am haeufigsten gefilterten Spalten einer Materialized View genauso wirksam wie auf einer normalen Tabelle und kann Lesezugriffe zusaetzlich beschleunigen, insbesondere wenn nur ein kleiner Ausschnitt der materialisierten Zeilen pro Abfrage benoetigt wird.

-- A plain view has no indexes of its own, only the base tables can be indexed
CREATE INDEX idx_orders_customer_id ON orders (customer_id);
CREATE INDEX idx_customers_status ON customers (status);
-- The optimizer uses these base-table indexes when the view is expanded

-- SQL Server: indexed view, physically materialized and index-backed
CREATE VIEW dbo.active_customer_summary WITH SCHEMABINDING AS
SELECT
  c.id,
  c.name,
  COUNT_BIG(*) AS order_count,
  SUM(o.total) AS lifetime_value
FROM dbo.customers c
JOIN dbo.orders o ON o.customer_id = c.id
WHERE c.status = 'active'
GROUP BY c.id, c.name;

CREATE UNIQUE CLUSTERED INDEX idx_acs_id ON dbo.active_customer_summary (id);

-- PostgreSQL: index directly on a materialized view, like a regular table
CREATE INDEX idx_acs_mv_lifetime_value
  ON active_customer_summary_mv (lifetime_value);

8. Wann welcher View-Typ die richtige Wahl ist

Eine normale View ist die richtige Wahl, wann immer absolute Datenaktualitaet unverzichtbar ist, die zugrunde liegende Abfrage moderat komplex bleibt oder die View primaer der Abstraktion und Zugriffskontrolle dient, nicht der Performance-Optimierung. Views eignen sich hervorragend, um komplexe Business-Logik hinter einer stabilen Schnittstelle zu verstecken, ohne dass Anwendungscode die zugrunde liegenden Tabellenstrukturen kennen muss, und ohne den zusaetzlichen Betriebsaufwand einer Refresh-Strategie zu erzeugen.

Eine Materialized View lohnt sich, sobald eine teure Abfrage wiederholt mit denselben oder aehnlichen Parametern ausgefuehrt wird und ein gewisser Datenverzug tolerierbar ist. Klassische Einsatzfaelle sind Dashboards mit aggregierten Kennzahlen, taegliche oder stuendliche Reports, Such-Indizes ueber denormalisierte Daten oder API-Endpunkte mit hohem Lesevolumen, bei denen die zugrunde liegenden Basisdaten sich vergleichsweise selten aendern. Wo beides zutrifft, kombinieren viele Systeme beide Ansaetze: eine Materialized View fuer die teure Grundaggregation, darauf aufbauend eine normale View fuer leichte, aktuelle Filterungen.

-- Combining both: a materialized view for the expensive base aggregation,
-- a plain view on top for light, always-current filtering

CREATE MATERIALIZED VIEW customer_revenue_base_mv AS
SELECT
  c.id AS customer_id,
  c.region,
  SUM(o.total) AS total_revenue,
  COUNT(o.id) AS order_count
FROM customers c
JOIN orders o ON o.customer_id = c.id
GROUP BY c.id, c.region;

-- Cheap, always up to date filtering on top of the materialized base
CREATE VIEW top_customers_this_view AS
SELECT customer_id, region, total_revenue
FROM customer_revenue_base_mv
WHERE total_revenue > 5000
ORDER BY total_revenue DESC;

9. View und Materialized View im direkten Vergleich

Die folgende Tabelle fasst die zentralen Unterschiede zusammen und dient als schnelle Entscheidungshilfe fuer die Wahl zwischen einer normalen View und einer Materialized View im konkreten Einsatzfall.

In der Praxis ist die Entscheidung selten endgueltig. Eine als normale View gestartete Abfrage, die im Laufe der Zeit immer komplexer und langsamer wird, ist ein klares Signal, die Umwandlung in eine Materialized View mit passender Refresh-Strategie zu pruefen, sobald der gemessene Datenverzug fuer den Anwendungsfall akzeptabel ist.

10. Zusammenfassung

Der Unterschied zwischen View und Materialized View laesst sich auf eine einzige Frage reduzieren: Wird die Abfrage bei jedem Zugriff neu berechnet, oder wird ihr Ergebnis gespeichert und periodisch aktualisiert? Eine normale View garantiert Aktualitaet ohne Speicherkosten, bezahlt dafuer aber mit voller Ausfuehrungszeit bei jedem Zugriff. Eine Materialized View liefert konstant schnelle Lesezugriffe, erkauft sich das aber mit Speicherplatz, Refresh-Aufwand und einem gewissen, kontrollierbaren Datenverzug.

Die richtige Wahl haengt nicht davon ab, welche Technik grundsaetzlich ueberlegen ist, sondern davon, wie teuer die zugrunde liegende Abfrage ist, wie oft sie ausgefuehrt wird und wie viel Staleness der jeweilige Anwendungsfall toleriert. Wer diese drei Fragen fuer jede komplexe Abfrage explizit beantwortet, trifft die Entscheidung zwischen View und Materialized View nicht aus Gewohnheit, sondern auf Basis konkreter Anforderungen.

11. FAQ: View vs. Materialized View