Slovník pojmů

Databázové schéma

Schéma je dohoda mezi datovým modelem, aplikací a provozem. Ruční změny produkční struktury bez migrace tuto dohodu rychle rozbíjejí.

Stručná definice

Struktura, podle níž databáze rozumí uloženým datům.

Databázové schéma určuje, jaké objekty databáze existují a jak spolu souvisejí: tabulky, jejich sloupce a typy, klíče, constrainty, indexy, view nebo sekvence. Aplikace, importy, reporty a migrace pak sdílejí stejný kontrakt pro ukládání a čtení dat.

Slovo schéma má v PostgreSQL ještě konkrétní technický význam: jde o namespace uvnitř jedné databáze, například public.orders nebo billing.invoices. Tento namespace není totožný s celým logickým návrhem databáze, i když je jeho součástí.

Jaký problém řeší

Srozumitelný a verzovaný datový kontrakt

Schéma dovoluje přezkoumat, jaká data systém vede, jaké má vztahy a co se smí změnit.

model zákazníků, objednávek, položek, produktů a skladových pohybů
verzování tabulek, sloupců, indexů a constraintů
spolupráce mezi aplikací, ORM, reporty a integračními službami
reprodukovatelné vytvoření vývojového, testovacího i produkčního prostředí
případné seskupení objektů do PostgreSQL namespace

SQL ukázka

PostgreSQL schema jako namespace

Tato krátká ukázka vysvětluje druhý význam slova schéma v PostgreSQL. Neznamená, že každá aplikace potřebuje více namespace nebo že tím získá hotovou multi-tenant izolaci.

CREATE SCHEMA billing;

CREATE TABLE billing.invoices (
    id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    order_id bigint NOT NULL
);

Jak funguje

Od doménových faktů k verzované struktuře

Textová alternativa: zákazník → objednávka → položka objednávky → produkt; schéma určuje atributy a pravidla všech vazeb.

Doménová fakta Zákazník, produkt, objednávka, položka, platba a sklad mají odlišný význam a životní cyklus.
Objekty schématu Fakta se promítnou do tabulek, sloupců, typů, klíčů, constraintů a indexů.
Vztahy Cizí klíče vyjádří, které záznamy na sobě závisí a co musí při změně zůstat platné.
Verzovaná změna Migrace mění schéma kontrolovaně a v pořadí slučitelném se starší i novou verzí aplikace.
Provoz a čtení SQL, ORM, importy a reporty pracují s aktuálním schématem; změna názvu či typu je změna rozhraní.

Důležité pojmy

Schéma zahrnuje více než diagram tabulek.

Diagram je užitečný pohled, ale nevystihne automaticky všechny constrainty, migrace a procesní pravidla.

Tabulka, sloupec a typ

Definují strukturu jednoho druhu záznamu a přípustné hodnoty jeho atributů.

Klíč, constraint a index

Klíče a constrainty chrání identitu a integritu. Index podporuje konkrétní přístupové vzory, není náhradou datového návrhu.

View a sekvence

View zpřístupňuje definovaný dotaz jako objekt. Sekvence může vytvářet číselné hodnoty; obojí je součást širší struktury.

Migrace

Je verzovaný krok, který schéma mění. Aktuální schéma je stav, ne seznam kroků, které k němu vedly.

PostgreSQL schema namespace

Umožňuje oddělit jmenné prostory objektů. Výběr nekvalifikovaného názvu ovlivňuje search_path, který má být nastaven uvážlivě.

Vztah k podobným pojmům

Návrh, namespace a mapování nejsou synonyma.

Každé z nich popisuje schéma z jiné perspektivy.

Databáze: Obsahuje data a objekty; schéma popisuje jejich strukturu nebo namespace uvnitř databáze.
Databázová tabulka: Jeden objekt širšího schématu, který drží konkrétní typ řádků.
Doctrine ORM: Mapuje PHP objekty, ale nemusí zachytit každý index, view, constraint či provozní detail.
Databázová migrace: Verzovaně přechází z jednoho stavu schématu do dalšího.

Výhody a omezení

Struktura musí žít společně s aplikací.

Přínosy

jasnější model dat a jejich vztahů
reprodukovatelné prostředí přes migrace
lepší review změn a dopadů na integrace
pravidla integrity blízko dat

Časté chyby

ruční změny produkce mimo migrace
považování PostgreSQL namespace za automatickou izolaci tenantů
změna názvu či typu bez kompatibility se starší aplikací
spoléhání na diagram místo skutečných constraintů a migrací
nepromyšlený search_path pro namespace s nedůvěryhodnými objekty

Praktický příklad

Schéma e-shopu jako dlouhodobé rozhraní

Schéma obsahuje customers, orders, order_items, products a inventory_movements. Určuje typy cen a časů, primární identity, cizí klíče, kontrolní pravidla i indexy pro administraci. ORM a SQL nad tímto kontraktem jen pracují.

Při nasazení nové funkce se schéma nemění ručně na produkci. Migrace přidá například nový nullable sloupec, aplikace jej začne umět číst a zapisovat, data se doplní a teprve později se pravidlo zpřísní.

Na co myslet

Názvy a změny schématu jsou dlouhodobý kontrakt.

Dobrá struktura je verzovaná, dokumentovaná a slučitelná s rolloutem aplikace.

verzovat schéma společně s kódem a kontrolovat migrace
neprovádět nezdokumentované ruční změny na produkci
název objektu posuzovat i jako rozhraní pro reporty a integrace
plánovat kompatibilní změny pro souběh staré a nové verze aplikace
nepovažovat více PostgreSQL schémat za obecně nejlepší model tenantů

Časté otázky

Schéma v praxi

Je databázové schéma totéž co PostgreSQL schema?

Ne úplně. Obecně jde o návrh databázových objektů; PostgreSQL používá schema také jako konkrétní namespace uvnitř jedné databáze.

Může ORM nahradit databázové schéma?

Ne. ORM může popsat část mapování, ale schéma zahrnuje také constrainty, indexy, pohledy, migrace a vlastnosti konkrétní databáze.

Proč schéma verzovat?

Aplikace musí vědět, s jakými tabulkami, typy a pravidly pracuje. Migrace drží vývoj, test a produkci ve vysvětlitelném stavu.

Jsou více PostgreSQL schémata nutná pro multi-tenant aplikaci?

Ne. Jsou jednou z organizačních možností, ale přinášejí vlastní provozní a migrační náklady. Volba záleží na modelu tenanta a správě dat.

Jak tento princip používám v praxi

Datový kontrakt propojuji s architekturou a nasazením.

Při vývoji řeším schéma, migrace, aplikaci i integrační dopady jako jeden celek, aby změny šly bezpečně zavádět a dohledat.

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