Databázový pohled (View)

Příklady z praxe

1. 01

   Pohled jako bezpečnostní filtr nad mzdami

   Personální tabulka obsahuje mzdy, ale manažeři potřebují jen kontakty a oddělení. Vytvoří se pohled bez citlivých sloupců a manažerská role dostane právo pouze na něj. Aplikace se tak nemusí starat o skrývání sloupců, protože samotná databáze citlivá data nikdy nevydá.

   CREATE VIEW zamestnanci_verejne AS
   SELECT id, jmeno, email, oddeleni_id
   FROM zamestnanci
   WHERE datum_odchodu IS NULL;
   
   REVOKE ALL ON zamestnanci FROM manazer;
   GRANT SELECT ON zamestnanci_verejne TO manazer;

2. 02

   Denní tržby v e-shopu a přechod na materializaci

   Report tržeb spojuje objednávky s položkami a agreguje po dnech. Jako běžný pohled se počítá při každém otevření dashboardu a nad miliony řádků trvá desítky sekund. Po převodu na materializovaný pohled s indexem nad dnem se dotaz vrací okamžitě a data se obnovují jednou za hodinu naplánovaným REFRESH.

   CREATE MATERIALIZED VIEW trzby_denne AS
   SELECT date_trunc('day', o.vytvoreno) AS den,
          SUM(p.cena * p.mnozstvi) AS trzba
   FROM objednavky o
   JOIN polozky p ON p.objednavka_id = o.id
   WHERE o.stav = 'zaplaceno'
   GROUP BY 1;
   
   CREATE INDEX ON trzby_denne (den);
   REFRESH MATERIALIZED VIEW CONCURRENTLY trzby_denne;

Časté omyly

MýtusPohled je rychlejší než ten samý dotaz napsaný ručně.

Ve skutečnostiPohled je jen uložený text dotazu, který se při použití vloží do plánu. Výkon je stejný jako u ručně napsaného dotazu; zrychlení přinese až materializovaný pohled nebo vhodný index.

MýtusPohled zabírá místo v databázi, protože v sobě drží data.

Ve skutečnostiKlasický pohled ukládá pouze definici a spotřebuje jednotky kilobajtů v katalogu. Data drží zdrojové tabulky. Místo na disku zabírá až materializovaný pohled, který výsledek skutečně uloží.

MýtusDo pohledu se nedá zapisovat.

Ve skutečnostiJednoduchý pohled nad jednou tabulkou bez agregace bývá zapisovatelný automaticky. U složitějších pohledů se zápis povolí triggerem nebo pravidlem INSTEAD OF, který určí, kam se data uloží.

Časté dotazy

Kdy použít databázový pohled místo dotazu v aplikaci?

Databázový pohled se vyplatí tehdy, když stejnou logiku potřebuje víc konzumentů: aplikace, BI nástroj, exportní skript i ruční dotazy analytiků. Definice pak žije na jednom místě a její oprava se projeví všude. Naopak dotaz specifický pro jednu obrazovku jedné aplikace patří spíš do kódu, kde jej má tým ve verzování a v code review. Rozhodujícím kritériem bývá vlastnictví logiky: pokud pravidlo patří datům, patří i do databáze.

Jak se verzují změny pohledů při nasazení?

Definice pohledů patří do migračních skriptů stejně jako tabulky. Většina týmů používá CREATE OR REPLACE VIEW, což zachová oprávnění, ale neumožní změnit pořadí ani typy existujících sloupců; při takové změně je nutné pohled smazat a vytvořit znovu a poté znovu přidělit práva. U řetězců závislých pohledů je potřeba respektovat pořadí, protože DROP na spodní pohled selže nebo si vyžádá CASCADE, který tiše smaže i nadřazené pohledy.

Proč je dotaz nad pohledem pomalý, i když má tabulka index?

Pomalý dotaz nad pohledem obvykle znamená, že se filtr z vnějšího dotazu nedostal dovnitř k tabulce. Blokovat jej může agregace, DISTINCT, okenní funkce nebo LIMIT v definici pohledu: databáze musí nejdřív spočítat celý vnitřní výsledek a teprve pak filtrovat. Pomáhá podívat se na EXPLAIN, přesunout filtr přímo do definice pohledu, případně pohled parametrizovat pomocí funkce vracející tabulku.

Jak často obnovovat materializovaný pohled?

Interval obnovy materializovaného pohledu se odvozuje od toho, jak stará data ještě dávají smysl pro rozhodování. Finanční uzávěrka snese noční obnovu, provozní dashboard chce minuty. V PostgreSQL umožňuje REFRESH MATERIALIZED VIEW CONCURRENTLY obnovu bez blokování čtenářů, vyžaduje ale unikátní index a je pomalejší. U velkých objemů bývá levnější inkrementální řešení: vlastní tabulka doplňovaná jen o nové řádky podle časového razítka.

Zdroje

1. CREATE VIEW(otevře se v novém okně)PostgreSQL Global Development Group
2. CREATE MATERIALIZED VIEW(otevře se v novém okně)PostgreSQL Global Development Group
3. CREATE VIEW(otevře se v novém okně)SQLite
4. Views (SQL Server)(otevře se v novém okně)Microsoft Learn

Související pojmy

• TriggerTrigger je kus kódu uložený v databázi, který se automaticky provede při určité události nad tabulkou, typicky před nebo po operaci INSERT, UPDATE či DELETE. Aplikace ho nevolá: spouští ho sám databázový stroj v rámci téže transakce, takže slouží k auditu, kontrole integrity nebo dopočítávání odvozených hodnot.
• A/B testováníA/B testování je řízený experiment, který porovnává dvě varianty stránky, funkce, ceny nebo sdělení na podobných skupinách uživatelů. Měří předem zvolenou metriku, například konverzi nebo retenci, a pomáhá rozhodnout, zda změna skutečně zlepšuje výsledek, nebo zda pozorovaný rozdíl mohl vzniknout náhodou.
• ACIDACID je sada čtyř vlastností databázové transakce: atomicity, consistency, isolation a durability. Zaručuje, že skupina zápisů proběhne jako jeden celek, neporuší definovaná pravidla databáze, nebude se nebezpečně míchat s jinými transakcemi a po potvrzení přežije pád systému, například při převodu peněz.
• Adaptive IconAdaptivní ikona je formát ikony aplikace na Androidu, který se místo jedné hotové bitmapy skládá z oddělených vrstev: pozadí a popředí. Systém výsledný tvar sám ořízne podle masky výrobce zařízení a může vrstvy animovat nebo přebarvit. Vývojář tak dodá jeden zdroj a launcher z něj vytvoří kruh, čtverec i squircle.
• Adresa v pamětiAdresa v paměti je číslo, kterým procesor jednoznačně označuje konkrétní buňku operační paměti, obvykle jeden bajt. Program pomocí adresy říká, odkud má data načíst nebo kam je zapsat. Adresy tvoří souvislý číselný rozsah, jehož velikost určuje šířka adresní sběrnice a architektura, typicky 32 nebo 64 bitů.
• AI agentAI agent je softwarový systém, který pomocí modelu umělé inteligence vnímá zadaný kontext, plánuje další kroky a samostatně volá nástroje nebo služby k dosažení cíle. Na rozdíl od jednorázového promptu udržuje stav úlohy, vyhodnocuje výsledky akcí a může opakovat postup, dokud nesplní zadání nebo nenarazí na limit.
• AndroidAndroid je operační systém postavený nad linuxovým jádrem, který vyvíjí Google a otevřeně uvolňuje jako projekt AOSP. Android pohání převážnou většinu chytrých telefonů, dále tablety, televize, hodinky i palubní systémy aut. Aplikace se pro něj píší hlavně v Kotlinu nebo Javě a distribuují přes Google Play i alternativní obchody.
• APIAPI je smluvené rozhraní, přes které spolu dva programy komunikují, aniž by jeden musel znát vnitřní fungování druhého. Definuje, jaké operace lze volat, jaká data se posílají a co se vrátí zpět.