Antwoord

In SQL zijn er twee types weergaven:

• Gewone weergaven (View): logische virtuele tabellen. Bewaren geen gegevens, een verzoek aan de VIEW genereert elke keer een subquery naar de oorspronkelijke tabellen.
• Gematerialiseerde weergaven (Materialized View): slaan de resultaten van de query fysiek op in een aparte tabel, die periodiek wordt bijgewerkt.

Gewone View zijn handig voor het abstraheren van complexiteit, het vereenvoudigen van toegang en het combineren van gegevens uit verschillende bronnen. Ze versnellen de verzoeken niet, omdat ze altijd on-the-fly worden gegenereerd.

Gematerialiseerde View bieden prestatievoordeel voor complexe rapportages en analyses, waar het belangrijk is om niet elke keer te wachten op aggregaties en joins. Ze moeten handmatig of volgens een schema worden geactualiseerd om verouderde gegevens te voorkomen.

Voorbeeld van een gewone VIEW:

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

Voorbeeld van een gematerialiseerde VIEW (PostgreSQL):

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

Vraag met een strikvraag

Is het mogelijk om gegevens in een VIEW bij te werken en hoe hangt dit af van het type VIEW?

Vaak wordt ten onrechte aangenomen dat VIEW's volledig identiek zijn aan tabellen wat betreft bijwerkbaarheid. IN WERKELIJKHEID:

• Gewone VIEW's staan zelden updates toe: alleen als er geen aggregaten, groepen of samengestelde/berekende velden zijn (en ook geen JOIN's of subqueries).
• Gematerialiseerde VIEW's kunnen helemaal niet direct worden bijgewerkt — alleen via REFRESH, anders ontstaat er een inconsistentie in de gegevens.

Voorbeelden van echte fouten door onbekendheid met de nuances van het onderwerp

---

Verhaal 1

Een BI-rapport werd opgebouwd via een gewone VIEW met verschillende JOIN's en aggregaten. Na een toename van de belasting steeg de tijd voor het opstellen van het rapport tot tientallen minuten. Een systeemanalist stelde een gematerialiseerde weergave voor, wat de tijd onmiddellijk verminderde tot seconden, omdat de gegevens in een aparte tabel konden worden opgeslagen.

---

Verhaal 2

Een ontwikkelaar probeerde tijdens de migratie naar Oracle een UPDATE uit te voeren via een gewone VIEW, wat een fout veroorzaakte: "view with group by is not updatable". De oorzaak was het gebruik van GROUP BY in de weergave.

---

Verhaal 3

In een bedrijf vergaten ze de gematerialiseerde weergave bij te werken na het importeren van nieuwe gegevens, waardoor er inconsistentie ontstond in de rapporten tussen verschillende gebruikers, omdat de analyses op verouderde gegevens uit deze VIEW werkten. Daarna werd er een automatische REFRESH aan het schema toegevoegd.