Salt la conținutul principal
Modulul 9 · Lecția 4 din 436/57 în curs~12 min
Lecții din modul (4/4)

Vizualizări și abstracție de date

De-a lungul lecțiilor noastre, veți fi observat că interogările (în special JOIN-uri complexe sau agregari precum GROUP BY) încep să devină lungi și pline de reguli și calcule.

Ce se întâmplă dacă ar exista o modalitate de a salva mental interogarea finalizată și de a o ascunde de la vedere, pretinzând de atunci că este, în toate intențiile și scopurile, un „tabel” normal al DB?

Bun venit în lumea Views.

CREATE VIEW

O vizualizare este în esență o interogare SQL persistentă, numită, dar se comportă la fel ca un tabel „virtual”!

SQL
CREATE VIEW user_spending AS
SELECT
  c.id,
  c.first_name,
  SUM(o.amount) as total_spent
FROM customers c
JOIN orders o ON c.id = o.customer_id
GROUP BY c.id;

Făcut! Acum, în loc să trebuiască mereu să refaceți acele JOIN și GROUP BY, trebuie doar să scrieți interogări perfect normale:

SQL
SELECT * FROM user_spending WHERE total_spent > 100;
-- Postgres dietro le quinte richiamerà automaticamente la grande formula.

Vizualizări și „date în timp real”

Un mit foarte des întâlnit este gândirea că Vizualizările preiau datele, calculează sume precum prețuri sau clasamente și produc niște instantanee triste persistente, ca o fotografie. Greșit (aproape întotdeauna)! În mod implicit, Vizualizările sunt virtuale: de fiecare dată când puneți numele unei Vizualizări în SELECT, Postgres în culise îmbină solicitarea dvs. rulând un calcul în timp real bazat pe starea DB la exact milisecunda respectivă. Deci nu veți citi niciodată date învechite.

Pentru ce sunt?

  • Simplitate: vizualizările protejează aplicațiile externe de modificări. Dacă echipa de front-end știe că trebuie să citească date din vizualizarea top_selling, nu trebuie să-și facă griji dacă mâine modificăm baza de date adăugând trei relații intermediare pentru a scoate cei mai vânduți!
  • Securitate și segregare: în bazele de date uriașe, o vizualizare poate preselecta și ascunde o parte din datele utilizatorilor de la dezvoltatorii externi, acordându-le acces (de exemplu) doar la o sub-vizualizare a analizelor curățate de nume reale.

Aruncarea unei vizualizări

La fel ca în tabelele, atunci când nu mai este nevoie, continuați cu comanda DROP:

SQL
DROP VIEW user_spending;

Încearcă

Exercițiu#sql.m9.l4.e1
Încercări: 0Se încarcă…

Creați o vizualizare (VIEW) numită „produse_de_valoare_înaltă”. Trebuie să se comporte ca un container care selectează toate cele 3 câmpuri esențiale (`id`, `name`, `price`) din tabelul 'produse', DAR numai și întotdeauna pentru acele produse care au un 'preț' mai mare de 50,00.

Se încarcă editorul...
Afișează indiciu

Scrieți CREATE VIEW view_name AS SELECT ... FROM ... WHERE ...

Soluție disponibilă după 3 încercări

Apelarea unei vizualizări

Exercițiu#sql.m9.l4.e2
Încercări: 0Se încarcă…

Deoarece fiecare exercițiu de pe platformă se desfășoară într-un mediu izolat (și curat), vizualizarea anterioară nu mai există în acest pas. Recreați vizualizarea „produse_de_valoare_înaltă” (încă cu produse cu preț > 50) și apoi, pe linia imediat următoare, executați o SELECTARE a întregului conținut ordonat în funcție de preț descendent (DESC) pentru a verifica dacă funcționează.

Se încarcă editorul...
Afișează indiciu

Nu uitați de ; între instrucțiunile SQL (puneți-l la sfârșitul primei rânduri)! Acest lucru permite Postgres să execute cele 2 sarcini în secvență.

Soluție disponibilă după 3 încercări