Slovník pojmů

PostgreSQL

PostgreSQL je relační databáze pro integritu dat, transakce a složitější dotazy. JSONB ji nemění v bezstarostné úložiště všeho do jednoho dokumentu.

Stručná definice

Zdroj pravdy pro vztahy, pravidla a transakční změny.

PostgreSQL ukládá data do tabulek s řádky a sloupci, ale jeho podstatnou výhodou není jen tabulkový tvar. Primární a cizí klíče, unikátní omezení, kontrolní pravidla, transakce a indexy dovolují chránit vztahy mezi objednávkou, položkami, platbou, zákazníkem a externími identifikátory i při souběhu.

V e-shopu nebo interním systému může databáze chránit invariants na poslední hranici, kterou obcházejí importy, konzole i paralelní requesty. ORM aplikaci zjednoduší práci s daty, ale nenahrazuje promyšlený relační návrh, constrainty ani měření skutečných dotazů.

Použití

Kde relační data potřebují integritu

PostgreSQL se používá pro data, která potřebují jasné vztahy, historii a atomické změny.

objednávky, položky, platby, vratky a účetní vazby
produkty, varianty, ceny, sklady a rezervace
uživatele, organizace, role a interní dokumenty
idempotentní importy s unikátním externím identifikátorem
relační data doplněná proměnlivým JSONB payloadem externího API

Praktický příklad

Marketplace objednávka v jedné transakci

Importer ukládá marketplace, external_order_id, stav a původní payload do JSONB. Unikátní constraint nad dvojicí marketplace a external_order_id zabrání dvěma paralelním retry založit stejnou objednávku. V jedné transakci se uloží objednávka, položky a integrační záznam.

Foreign key chrání vazbu položek na objednávku a index podle stavu a času odpovídá běžnému přehledu administrace. Pokud krok selže, rollback vrátí všechny lokální změny. JSONB se indexuje až v okamžiku, kdy reálné dotazy často hledají uvnitř externího payloadu.

CREATE TABLE marketplace_order (
  id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  marketplace text NOT NULL,
  external_order_id text NOT NULL,
  status text NOT NULL,
  payload jsonb NOT NULL,
  created_at timestamptz NOT NULL DEFAULT now(),
  CONSTRAINT marketplace_order_external_key
    UNIQUE (marketplace, external_order_id)
);

CREATE INDEX marketplace_order_status_created_idx
  ON marketplace_order (status, created_at DESC);

Jak funguje

Od schématu po commit nebo rollback

Databáze spojí návrh dat, pravidla a souběžné transakční provedení.

Schéma Tabulky, typy, identity sloupce, vztahy a constrainty vymezí povolený stav dat.
Constrainty a indexy UNIQUE, FOREIGN KEY, CHECK a NOT NULL chrání pravidla; indexy podporují konkrétní dotazy za cenu zápisu a prostoru.
Transakce Seskupí související změny do atomického celku. COMMIT je zveřejní, ROLLBACK je zahodí.
MVCC Víceverzní řízení souběhu dává dotazům konzistentní pohled a omezuje blokování čtení a zápisů.
Planner a provoz Planner zvažuje statistiky a indexy; autovacuum, zálohy, obnova a sledování dlouhých transakcí jsou součást provozu.

Důležité pojmy

Datová pravidla mají být vyjádřená tam, kde platí.

Aplikační validace je důležitá pro uživatele; databázová pravidla chrání stav i při souběhu.

Klíče a constrainty

PRIMARY KEY identifikuje řádek, FOREIGN KEY udržuje referenci, UNIQUE brání duplicitě a CHECK hlídá pravidlo nad daným řádkem. Ne každý businessový vztah lze vyjádřit jedním CHECK.

Transakce a izolace

Výchozí READ COMMITTED dává každému příkazu pohled na data potvrzená před jeho začátkem. Vyšší izolace má jiné kompromisy a po serializačním konfliktu může vyžadovat opakování transakce.

Indexy a planner

B-tree je běžný pro rovnost, rozsahy a řazení; existují i GIN, GiST, SP-GiST a BRIN. Index není automatická optimalizace: mění rychlost zápisu a ověřuje se přes EXPLAIN.

JSONB

JSONB drží rozložený JSON, který lze indexovat. Hodí se pro proměnlivý payload, ne pro skrytí klíčových vztahů, identifikátorů a pravidel do jednoho sloupce.

Vztah k podobným pojmům

PostgreSQL není ORM, cache ani univerzálně nejlepší databáze.

Volba úložiště vychází z modelu dat, dotazů a provozních potřeb.

Doctrine ORM: Mapuje objekty na relační data. Neurčuje sám správné constrainty, indexy ani hranice transakce.
Redis: In-memory cache a koordinační vrstva vedle databáze. Obvykle není zdrojem pravdy pro objednávky a vztahy.
MySQL a MariaDB: Také relační systémy, ale liší se datovými typy, plánováním, JSON funkcemi i provozními zvyklostmi; nejde o žebříček lepší–horší.
SQLite a dokumentová databáze: SQLite se hodí pro jiný rozsah nasazení, dokumentové úložiště pro jiný model dat. JSONB nenahrazuje uváženou volbu modelu.

Výhody a omezení

Silná pravidla a dotazy mají i provozní cenu.

Přínosy

integrita dat přes klíče, constrainty a transakce
souběh přes MVCC a bohaté datové typy
více indexových strategií pro skutečné dotazy
kombinace relačního modelu s proměnlivým JSONB payloadem

Rizika

dlouhé transakce komplikují úklid starých verzí
nadbytečné indexy zpomalují zápis a zabírají prostor
JSONB může skrýt vazby, validaci a cílené indexování
validace jen v aplikaci neochrání souběžný import nebo jinou službu

Hranice použití

Relační návrh není překážka, ale vědomá práce s realitou dat.

PostgreSQL je přirozená volba pro objednávky, platby, sklady a integrační stavy, kde chyba vztahu nebo duplicita stojí více než přesně pojmenovaný sloupec a constraint. Pro malá lokální data nebo jiný přístupový vzor může být vhodnější jiné úložiště.

Databáze nevyřeší všechny procesy mezi více systémy. Transakce chrání lokální změny; předání události, externí API a retry potřebují vlastní návrh. U kritické změny se vyplatí spojit constraint, hranici transakce, monitorování a idempotentní integraci.

Na co myslet

Integritu měřit a prosazovat na správné hranici.

Datový model má vycházet ze skutečných dotazů a rizik, ne z katalogu funkcí databáze.

PRIMARY KEY, FOREIGN KEY, UNIQUE a NOT NULL pro důležité invariants
krátké transakce s jasnou hranicí a zpracováním konfliktu
indexy podle EXPLAIN a měřeného workloadu, ne na každý sloupec
JSONB jen pro proměnlivý doplněk, s konkrétními dotazy a indexy
zálohy, obnova, monitoring autovacuum a dlouhých transakcí

Časté otázky

Co PostgreSQL vyřeší a co ne

Nahrazuje JSONB relační návrh?

Ne. Hodí se pro proměnlivý doplněk, například payload externího API. Klíčové vztahy a pravidla je obvykle lepší vyjádřit sloupci a constrainty.

Proč nestačí validace ve formuláři nebo API?

Změna může přijít z importu, konzole či souběžného requestu. Databázový constraint chrání stav na poslední společné hranici.

Je každý dotaz bez indexu chyba?

Ne. U malé tabulky nebo nevhodně selektivního filtru může být sekvenční scan správná volba. Rozhoduje plán a naměřené chování.

Řeší MVCC všechny souběžné konflikty?

Ne. Dává konzistentní snapshoty a omezuje blokování, ale businessový konflikt stále potřebuje správnou transakci, constraint nebo cílené zamykání.

Jak navrhuji data v praxi

Databázová pravidla používám jako součást spolehlivého procesu.

V e-commerce a integracích řeším relační model, transakce, constrainty, výkonné dotazy i dohledání stavu dat.

Jak pracuji s databázemi Nezávazně probrat projekt