ProgrammazioneSviluppatore SQL / Architetto DB

Quali sono i tipi di viste (VIEW) in SQL? Come funzionano le viste materializzate e in cosa si differenziano dalle normali VIEW? Quando è opportuno usarle?

Supera i colloqui con l'assistente IA Hintsage

Risposta

In SQL ci sono due tipi di viste:

  • Viste normali (View): tabelle virtuali logiche. Non memorizzano dati, la query a una VIEW genera ogni volta una sottoquery alle tabelle di origine.
  • Viste materializzate (Materialized View): memorizzano fisicamente il risultato di una query in una tabella separata, che viene aggiornata periodicamente.

Le normali View sono utili per astrarre la complessità, semplificare l'accesso, unire dati provenienti da diverse fonti. Non accelerano le query, poiché vengono sempre generate al volo.

Le Viste materializzate offrono un vantaggio in termini di prestazioni per report complessi e analisi, dove è importante non dover attendere ogni volta aggregazioni e join. Devono essere aggiornate manualmente o secondo un programma, affinché i dati non diventino obsoleti.

Esempio di una normale VIEW:

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

Esempio di una vista materializzata (PostgreSQL):

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

Domanda trabocchetto

È possibile aggiornare i dati in una VIEW e come dipende dal tipo di VIEW?

Spesso si commette l'errore di considerare che le VIEW siano completamente identiche alle tabelle in termini di aggiornabilità. IN REALTÀ:

  • Le VIEW normali raramente consentono aggiornamenti: solo se non ci sono campi aggregati, di gruppo o compositi/calcolati (e questo in assenza di JOIN e sottoquery).
  • Le Viste Materializzate non possono essere aggiornate direttamente — solo tramite REFRESH, altrimenti si verifica una disallineamento dei dati.

Esempi di errori reali a causa della mancanza di conoscenza delle sottigliezze dell'argomento


Storia 1

Un report BI è stato costruito tramite una normale VIEW con diversi JOIN e aggregati. Dopo un aumento del carico, il tempo di creazione del report è aumentato fino a decine di minuti. L'analista di sistema ha proposto una vista materializzata, riducendo istantaneamente il tempo a secondi, poiché i dati sono stati memorizzati in una tabella separata.


Storia 2

Uno sviluppatore, durante la migrazione a Oracle, ha tentato di eseguire un UPDATE tramite una normale VIEW, causando un errore: "view with group by is not updatable". La causa era l'uso di GROUP BY nella vista.


Storia 3

In una azienda dimenticavano di aggiornare la vista materializzata dopo l'importazione di nuovi dati, portando a un disallineamento tra i report di diversi utenti, poiché l'analisi lavorava con dati obsoleti provenienti da questa VIEW. Dopo hanno aggiunto un REFRESH automatico secondo un programma.