09-05 tancava prometent "l'arsenal que fa mantenible tot l'anterior", i la primera eina d'aquest arsenal és la més senzilla de totes: donar nom a una consulta. Una vista és exactament això —una consulta desada a la base de dades amb un nom— i no sembla gran cosa fins que comptes quantes vegades has copiat en aquest curs el mateix JOIN de quatre taules i la mateixa expressió quantitat * preu_unitari * (1 - descompte).

En aquesta lliçó veuràs què és i què no és una vista (no desa dades: desa la definició), com crear-la, reemplaçar-la i esborrar-la amb les seves regles exactes, els cinc motius reals pels quals es fan servir —amb un cas de BotigaVerda per a cadascun, inclòs l'esborrat lògic que 05-04 va deixar pendent—, quan PostgreSQL deixa escriure a través d'una vista i què és WITH CHECK OPTION, per què una vista no és una memòria cau i què passa en imbricar-les, i les vistes materialitzades que 08-04 va remetre aquí: les que sí que desen dades, amb el seu REFRESH i el seu preu.

1. Què és una vista i què no és
2. CREATE VIEW, CREATE OR REPLACE VIEW, DROP VIEW
3. Els cinc motius, amb un cas cadascun
4. Vistes actualitzables i WITH CHECK OPTION
5. Rendiment: la vista s'expandeix, no es cacheja
6. Vistes materialitzades
7. Metadades: on viuen les vistes
8. Errors habituals i consells
9. Exercicis
10. Conclusió

Una vista és una consulta SELECT emmagatzemada a l'esquema amb un nom. Quan la consultes, el motor substitueix el nom per la seva definició i executa la consulta resultant contra les taules reals.

Aquest diagrama és tota la lliçó en una imatge: la vista desapareix abans d'executar-se. És sucre sintàctic amb nom i permisos propis, no una capa d'emmagatzematge.

(Totes les vistes d'aquesta lliçó —v_productes_actius, v_detall_vendes, v_vendes_per_categoria, v_clients_public, mv_vendes_mensuals— són objectes d'exemple d'aquesta lliçó: no formen part de l'esquema canònic de BotigaVerda de 01-06.)

Les tres operacions i les seves regles:

Aquesta restricció d'OR REPLACE és la que fa perdre més temps:

En canvi, afegir al final sí que es pot: SELECT p.id, p.nom, p.categoria_id, p.preu, p.stock, p.proveidor_id funciona sense protestar.

La raó és la mateixa que feia delicat un ALTER TABLE a 05-06: altres consultes i altres vistes depenen de la posició i del tipus de cada columna. Per canviar la forma d'una vista cal fer DROP VIEW + CREATE VIEW, i això obliga a recrear també tot el que en depenia. ALTER VIEW existeix, però només per al que és perifèric: reanomenar la vista o una columna, canviar de propietari o d'esquema.

Fa des del mòdul 3 que escrius aquestes quatre línies de JOIN. S'escriuen una vegada:

I a partir d'aquí, una consulta de negoci es llegeix com una frase:

(5 primeres de 47 files.) I SELECT COUNT(*), ROUND(SUM(import), 2) FROM v_detall_vendes retorna 47 i 727.95: les xifres canòniques del curs, ara a un SELECT de distància.

Aquest motiu és més important que l'anterior i es veu pitjor. A la vista hi ha una decisió de negoci escrita una sola vegada: l'import d'una línia és quantitat * preu_unitari * (1 - descompte), arrodonit a dos decimals, sense despeses d'enviament. Si aquesta fórmula viu copiada en catorze informes, tard o d'hora tres d'ells oblidaran el (1 - descompte) i la direcció rebrà tres xifres diferents de facturació a la mateixa reunió.

Una vista és el lloc on es defineix una mètrica. La versió agregada, recolzada en l'anterior:

Les cinc categories amb vendes i les seves xifres canòniques. Complements no hi apareix perquè el JOIN sobre les vendes la descarta (04-05); per veure-la amb 0 caldria partir de categories amb un LEFT JOIN. Fixa't a més que aquesta vista està construïda sobre una altra vista: és legal i molt còmode, amb el matís de l'apartat 5.

Aquí es tanca la promesa de 05-04. L'esborrat lògic amb actiu = FALSE tenia un inconvenient enorme: cal recordar-se d'escriure WHERE actiu a tot arreu, i el dia que algú se n'oblidi, un producte descatalogat apareixerà a la botiga.

La vista v_productes_actius de l'apartat 2 retorna 19 de les 20 files de productes: les Càpsules d'espirulina (producte 20, actiu = FALSE) no hi són, i no hi ha manera que s'hi colin. La regla operativa és senzilla: l'aplicació consulta la vista; només el manteniment del catàleg toca la taula. El filtre deixa de ser una cosa que cal recordar i passa a ser una cosa que hi és.

A 05-06 vas veure el patró expand/contract: per reanomenar una columna sense aturar el servei s'afegeix la nova, s'escriuen totes dues durant un temps i es retira la vella. Suposa ara que productes.nom passa a dir-se nom_comercial. Les consultes de l'aplicació que apuntaven a productes.nom es trenquen totes; les que apuntaven a la vista no, perquè n'hi ha prou amb redefinir-la amb SELECT p.nom_comercial AS nom, ... i el canvi queda absorbit allà dins.

La vista actua com a contracte estable: per fora continua havent-hi una columna nom, i per dins l'esquema pot evolucionar. És la mateixa idea que una interfície en programació, i és el motiu pel qual molts equips exposen als informes i a les eines de BI només vistes, mai taules.

Una vista pot ometre columnes i files. clients té email, que és una dada personal, i referit_per_id, que és informació comercial interna:

Qui la consulti no veurà mai cap adreça de correu electrònic, perquè no és a la vista. El mateix amb les files: WHERE pais = 'Espanya' a la definició crea una vista que només mostra el mercat nacional.

Això és una eina de seguretat, i aquí només l'esmentem. Perquè serveixi d'alguna cosa cal treure el permís sobre la taula i donar-lo sobre la vista —GRANT SELECT ON v_clients_public TO ...—, i això, juntament amb els rols i el control d'accés a nivell de fila, és matèria d'11-03.

Sorpresa raonable: sobre una vista de vegades s'hi pot escriure. PostgreSQL la considera automàticament actualitzable —INSERT, UPDATE i DELETE funcionen sense més— quan compleix totes aquestes condicions:

UPDATE v_productes_actius SET preu = 13.00 WHERE id = 1; respon UPDATE 1, i el canvi ha anat a la taula productes. I ara el problema interessant. Afegim actiu a la vista —recorda: afegir al final sí que es pot— per poder escriure-la:

I l'oli d'oliva acaba de desaparèixer de la vista. Has escrit, a través d'una finestra, una fila que la finestra ja no mostra: l'UPDATE diu que ha tocat una fila, però tornar-la a consultar és impossible des d'aquí. A això se'n diu marxar per la porta del darrere, i es tanca així:

Amb WITH CHECK OPTION, tota fila inserida o modificada ha de continuar complint el WHERE de la vista:

Té dues variants: WITH LOCAL CHECK OPTION comprova només la condició d'aquesta vista, i WITH CASCADED CHECK OPTION la d'aquesta i la de totes les vistes sobre les quals es recolza —és el que s'aplica si no dius res—.

I per a les vistes que no són actualitzables automàticament —v_detall_vendes, per exemple— PostgreSQL ofereix dues sortides: un disparador INSTEAD OF, que intercepta l'escriptura i decideix a mà quines taules toca, o el sistema de regles (CREATE RULE), més antic i desaconsellat. La forma moderna és el disparador, i és exactament el que veuràs a 10-05.

Aquest és el malentès més car de la lliçó: una vista no desa res i no estalvia ni un microsegon de feina. El planificador la substitueix per la seva definició i optimitza el conjunt.

La bona notícia és que aquesta substitució és intel·ligent: els filtres de fora s'empenyen cap a dins.

Fixa't en el Filter: pais = 'França': ha baixat fins a l'escaneig de clients. La vista no ha materialitzat 47 files per filtrar-les després; el filtre forma part del pla. I en aquest pla la paraula v_detall_vendes no apareix enlloc, que és justament el que cal entendre.

El risc apareix amb la imbricació. v_vendes_per_categoria es recolza en v_detall_vendes, que uneix quatre taules: dos nivells encara es llegeixen bé. Però en bases de dades amb anys a sobre és habitual trobar una vista sobre una vista sobre una vista, cadascuna amb els seus JOIN i els seus LEFT JOIN "per si de cas"; en expandir-les totes, el planificador es troba amb una consulta de vint taules que no sap reordenar —a partir de join_collapse_limit, 8 per omissió, deixa de provar combinacions— i tria un pla mediocre. Els símptomes són inconfusibles: una consulta que demana tres columnes triga quatre segons i el seu EXPLAIN ANALYZE és ple de taules que no havies demanat.

Tres regles pràctiques: dos nivells d'imbricació com a màxim (si en necessites més, el nivell intermedi probablement vol ser una CTE dins de la consulta final, 10-02, o una vista materialitzada); davant d'una vista lenta, EXPLAIN sobre la consulta que la fa servir, no sobre la vista sola (08-05); i res d'ORDER BY a la definició, que no es garanteix que sobrevisqui a l'expansió.

Aquí es tanca la promesa de 08-04. Una vista materialitzada sí que desa les files a disc: és el resultat d'una consulta congelat en el temps.

La resposta és SELECT 12, no CREATE VIEW: ha executat la consulta i ha escrit les seves 12 files.

(4 primeres de 12 files; la sèrie completa, de 2025-03 a 2026-02, és la que faràs servir a 10-03.) Ara es llegeix de disc sense tocar comandes ni linies_comanda. I amb això arriba el defecte: si demà entra la comanda 21, aquesta taula continuarà dient el mateix. Les dades es queden com estaven fins que algú les refresqui.

Aquest requisit no és un caprici: per aplicar diferències cal poder identificar cada fila, i això exigeix una clau — aquí, CREATE UNIQUE INDEX ux_mv_vendes_mensuals ON mv_vendes_mensuals (mes);. Altres detalls que es descobreixen tard: es pot crear buida amb WITH NO DATA (i llavors consultar-la dona error fins al primer REFRESH); admet els seus propis índexs, com una taula; i no es refresca sola —cal cridar-la des d'un cron, des del planificador de l'aplicació o des de pg_cron.

Quan compensa una materialitzada, en concret: l'informe triga segons, es consulta moltes vegades al dia, i a ningú no li importa que les dades siguin de fa una hora. El quadre de comandament de direcció de BotigaVerda és l'exemple perfecte; l'estoc disponible del carretó, exactament el contrari.

A psql, \dv llista les vistes, \dm les materialitzades i \d+ v_detall_vendes mostra les columnes i la definició. Des de SQL, SELECT viewname, viewowner FROM pg_views WHERE schemaname = 'public' i, sobretot, SELECT pg_get_viewdef('v_productes_actius'::regclass, TRUE): aquest segon argument a TRUE retorna la definició formatada, i és la manera correcta de versionar vistes —es bolca, es desa al repositori al costat del codi i es revisa com qualsevol altre font—. També existeixen les vistes de l'estàndard (information_schema.views) i, per al graf de dependències —"què es trenca si esborro aquesta vista?"—, pg_depend.

Nota de dialecte:

Motor	Vistes	OR REPLACE	Materialitzades
PostgreSQL	Sí, actualitzables si són simples	Sí, només afegint columnes al final	Sí, amb REFRESH manual
MySQL 8	Sí, actualitzables, amb WITH CHECK OPTION	Sí	No existeixen: s'emulen amb una taula i un esdeveniment programat
SQLite	Sí, només lectura	No (DROP + CREATE)	No
SQL Server	Sí	CREATE OR ALTER VIEW	Sí, s'anomenen indexed views i es mantenen soles (amb moltes restriccions)
Oracle	Sí	CREATE OR REPLACE VIEW, sense la restricció de columnes	Sí, amb refresc incremental (FAST REFRESH) i automàtic

• Creure que una vista accelera alguna cosa. Executa exactament la mateixa feina. El que desa dades és la vista materialitzada; una vista normal només desa text.
• Intentar reanomenar o treure una columna amb CREATE OR REPLACE VIEW. cannot change name of view column. Només es poden afegir columnes al final; per a la resta, DROP + CREATE i recrear el que en depengués.
• Imbricar vistes sobre vistes sobre vistes. En expandir-les, el planificador veu una consulta de vint taules i deixa de reordenar (join_collapse_limit). Màxim dos nivells.
• Posar ORDER BY a la definició. No està garantit que sobrevisqui i fa nosa: l'ordre el demana qui consulta.
• Escriure per una vista amb WHERE sense WITH CHECK OPTION. Pots inserir o actualitzar files que la vista ja no mostra, i desapareixen davant dels teus ulls. I esperar que un INSERT funcioni sobre una vista amb JOIN o GROUP BY: no és automàticament actualitzable (cannot insert into view), cal un disparador INSTEAD OF (10-05).
• Oblidar el REFRESH. Una vista materialitzada sense procés de refresc és un informe congelat que la direcció llegeix com si fos d'avui. I sense índex UNIQUE no hi ha CONCURRENTLY: cada refresc bloquejarà les lectures.
• Fer servir una vista com a mecanisme de seguretat sense treure el permís sobre la taula. No protegeix res: qui pugui llegir clients continuarà llegint els correus (11-03).
• Consell: anomena les vistes amb un prefix (v_, mv_), i versiona'n les definicions amb pg_get_viewdef(..., TRUE). Una vista creada a mà en producció que ningú no té al repositori és deute tècnic invisible.
• Consell: una vista per mètrica de negoci. L'objectiu real no és escriure menys, és que la facturació es calculi igual a tot arreu.

Màrqueting vol treballar amb una vista v_clients_valor que doni, per a cadascun dels 15 clients: id, nom complet, país, nombre de comandes, unitats comprades i facturació (0 si no ha comprat mai).

1. Escriu-la. Vigila el tipus de JOIN i el COALESCE.
2. Consulta-la ordenada per facturació descendent i comprova que els clients 13, 14 i 15 surten amb zeros i que la suma de la columna dona 727,95 €.
3. És actualitzable automàticament? Justifica-ho amb la taula de l'apartat 4.

Sobre v_productes_actius definida amb WITH CHECK OPTION, prediu el resultat de cada sentència i després comprova-ho:

El quadre de comandament de direcció executa cada vegada que s'obre una consulta que triga 4 segons: facturació per mes i categoria des de l'inici de l'activitat. S'obre unes 200 vegades al dia i s'accepta un desfasament d'una hora.

1. Vista, vista materialitzada o taula de resum? Justifica-ho amb la taula comparativa.
2. Escriu l'objecte triat i el que calgui per poder refrescar-lo sense bloquejar qui l'estigui consultant.
3. Què canviaria si el requisit fos "les dades han de ser del segon actual"?

Solució 1

1. El LEFT JOIN no és negociable: amb INNER desapareixerien els tres clients sense comandes.

(4 primeres de 15 files.) Els clients 13, 14 i 15 tanquen amb 0 i 0.00, i SELECT SUM(facturacio) FROM v_clients_valor dona 727.95. El COUNT(DISTINCT co.id) és obligatori: amb COUNT(co.id) la Lucía tindria 9 "comandes", una per línia (04-04).

3. No és actualitzable automàticament, i falla en tres requisits alhora: té tres taules al FROM, té GROUP BY i té agregats al SELECT. Un UPDATE sobre ella donaria cannot update view "v_clients_valor", amb la pista que cal un disparador INSTEAD OF. I té sentit: què hauria de fer la base de dades si li demanes "posa la facturació de la Sofia a 200 €"?

Solució 2

a) Funciona: UPDATE 1. La vista és actualitzable —una sola taula, sense agregats—, la fila 5 està activa abans i després, i el canvi va a productes.

b) UPDATE 1, i després COUNT retorna 18. L'UPDATE va contra la taula, així que WITH CHECK OPTION no hi intervé: només vigila les escriptures fetes a través de la vista. El tomàquet desapareix de v_productes_actius sense cap més avís, que és precisament el comportament desitjat de l'esborrat lògic.

c) Funciona: INSERT 0 1. L'INSERT no esmenta actiu, així que la fila nova pren el DEFAULT TRUE de la taula, compleix el WHERE de la vista i WITH CHECK OPTION la deixa passar. Hauria fallat escrivint actiu a FALSE explícitament, o si el WHERE filtrés per una columna el valor per omissió de la qual no el satisfés. Recarrega l'script després: acabes d'afegir un producte 21 al catàleg.

d) Falla, perquè v_vendes_per_categoria en depèn:

DROP VIEW v_detall_vendes CASCADE funcionaria, i esborraria també v_vendes_per_categoria sense preguntar. És el perill de la imbricació de l'apartat 5, ara en forma de dependència.

Solució 3

1. Vista materialitzada. Els tres criteris coincideixen amb la columna del mig de la taula: la lectura és cara (4 s), es repeteix molt (200 vegades al dia = 800 segons de CPU diaris) i es tolera desfasament. Una vista normal no estalviaria res; una taula de resum mantinguda amb disparadors donaria dades instantànies, però a canvi de complexitat i d'un cost per cada INSERT a linies_comanda que aquí ningú no ha demanat.

2.

I al cron, cada hora: REFRESH MATERIALIZED VIEW CONCURRENTLY mv_vendes_mes_categoria;. Sense aquest índex únic, CONCURRENTLY falla i el refresc pren ACCESS EXCLUSIVE, deixant el quadre de comandament inaccessible durant els 4 segons del recàlcul.

3. Si les dades han de ser del segon actual, la materialitzada queda descartada: una vista normal ben indexada (mòdul 8) i, si tot i així no baixa dels 4 segons, una taula de resum mantinguda amb disparadors (10-05), amb tot el seu cost de complexitat i el seu risc de desincronització. La pregunta honesta, abans de res, és si "del segon actual" és un requisit de debò o un costum: en un informe mensual gairebé mai no ho és.

La primera eina del mòdul 10 és també la més barata:

• Una vista és una consulta amb nom. No emmagatzema dades, s'expandeix dins de la consulta que la fa servir —fins al punt que el seu nom no apareix a l'EXPLAIN— i per tant no accelera res.
• CREATE OR REPLACE VIEW només permet afegir columnes al final: ni reanomenar, ni treure, ni reordenar, ni canviar tipus. La resta és DROP + CREATE, arrossegant el que en depengués.
• Els cinc motius: simplificar (els quatre JOIN de v_detall_vendes, 47 línies i 727,95 €), estandarditzar una mètrica perquè la facturació es calculi igual a tot arreu, encapsular l'esborrat lògic (v_productes_actius, 19 de 20 productes — la promesa de 05-04), desacoblar l'aplicació de l'esquema físic com a contracte estable davant de l'expand/contract de 05-06, i exposar només una part de les dades (amb els permisos a 11-03).
• Una vista és actualitzable automàticament si ve d'una sola taula, sense agregats, sense DISTINCT, sense GROUP BY i amb columnes simples; WITH CHECK OPTION impedeix escriure files que la mateixa vista no mostraria. Per a la resta, disparador INSTEAD OF (10-05).
• Imbricar vistes és còmode i perillós: passats dos nivells, el planificador deixa de reordenar els JOIN i el pla es degrada. Davant del dubte, EXPLAIN de la consulta completa (08-05).
• Les vistes materialitzades sí que desen files: 12 mesos precalculats que es llegeixen a l'instant i envelleixen fins al REFRESH. CONCURRENTLY evita bloquejar les lectures, però exigeix un índex UNIQUE. Compensen en informes cars que toleren dades de fa una hora.

Una vista resol el problema de reutilitzar una consulta entre sessions i entre persones. Però moltes vegades el que vols no és reutilitzar-la, sinó entendre-la: descompondre una consulta de quaranta línies en passos amb nom, aquí i ara, sense crear cap objecte permanent. A la lliçó següent, expressions de taula comunes (CTE), posaràs WITH davant del SELECT i veuràs com les taules derivades imbricades de tres nivells de 07-04 es converteixen en una llista de passos llegibles; encadenaràs diverses CTE on cadascuna es recolza en l'anterior; entendràs per què el que diuen els tutorials antics sobre materialització va deixar de ser cert a PostgreSQL 12; i, sobretot, escriuràs la teva primera consulta recursiva per recórrer per fi la jerarquia completa d'empleats i la cadena de referits que 03-06 va deixar a mitges.