Jan Mikoláš
Slovník pojmů
Databázový constraint
Databázová pravidla chrání data i mimo jednu requestovou cestu. Validace v aplikaci je nenahrazuje a constraint zase nenahrazuje celý business proces.
Stručná definice
Poslední společná hranice integrity uložených dat.
Constraint chrání pravidlo, které musí platit při každém zápisu. Může vyžadovat povinnou měnu, jedinečnou dvojici marketplace a externího ID, nezápornou cenu nebo existující objednávku pro položku. Databáze tak pravidlo vyhodnotí také při importu, CLI nebo paralelních requestech.
Aplikační validace má jinou úlohu: umí uživateli ukázat chybu ještě před zápisem a pracuje s kontextem formuláře. Nemůže ale sama bezpečně chránit společný stav proti všem cestám zápisu a souběžným závodům.
Jaký problém řeší
Pravidla, která mají platit bez ohledu na vstupní kanál
Constrainty dávají databázi možnost odmítnout stav, který je z principu neplatný.
- NOT NULL pro povinnou cenu, měnu nebo zákazníka
- UNIQUE pro externí ID jedinečné v rámci marketplace
- CHECK pro nezápornou částku a platný rozsah množství
- PRIMARY KEY pro hlavní identitu řádku
- FOREIGN KEY pro položku odkazující na existující objednávku
- idempotentní import chráněný unikátní kombinací hodnot
SQL ukázka
PostgreSQL pravidla pro marketplace objednávku
CHECK nad částkou nenahradí NOT NULL: neznámá hodnota NULL by samotným porovnáním neznamenala platnou cenu.
CREATE TABLE marketplace_orders (
id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
marketplace text NOT NULL,
external_order_id text NOT NULL,
currency char(3) NOT NULL,
total_amount numeric(12, 2) NOT NULL,
customer_id bigint NOT NULL,
CONSTRAINT marketplace_orders_external_id_key
UNIQUE (marketplace, external_order_id),
CONSTRAINT marketplace_orders_total_amount_check
CHECK (total_amount >= 0),
CONSTRAINT marketplace_orders_customer_id_fkey
FOREIGN KEY (customer_id) REFERENCES customers (id)
);Jak funguje
Od invariantu k odmítnutí neplatného zápisu
Textová alternativa: formulář může chybu zachytit předem, konečné pravidlo však při zápisu vyhodnotí databáze.
- Návrh invariantu Určí se stabilní pravidlo, například jedinečnost externí objednávky v marketplace.
- Vhodný mechanismus NOT NULL, UNIQUE, CHECK, PRIMARY KEY a FOREIGN KEY vyjadřují rozdílné druhy omezení.
- Aplikační validace Formulář nebo API vrátí srozumitelnou chybu, ale nespoléhá na ni jako na jedinou ochranu.
- Zápis v transakci Databáze pravidlo ověří při vložení či změně řádku.
- Výsledek Platný stav projde; porušení constraintu zápis odmítne a aplikace chybu přeloží do svého kontextu.
Důležité pojmy
Každé pravidlo má přiměřený mechanismus.
Pojmenování constraintu pomáhá při migraci, diagnostice a převodu chyby na aplikaci.
NOT NULL a DEFAULT
NOT NULL nedovolí chybějící hodnotu. DEFAULT pouze doplní hodnotu, když ji INSERT vynechá; není sám o sobě constraintem.
UNIQUE a PRIMARY KEY
UNIQUE chrání jedinečnost hodnoty nebo kombinace. PRIMARY KEY určuje hlavní identitu a nepřipouští NULL. V PostgreSQL UNIQUE pro vynucení používá index.
FOREIGN KEY
Chrání odkaz na vhodný řádek jiné tabulky. Není to totéž jako asociace v ORM ani jako aplikační autorizace.
CHECK
Kontroluje výraz nad zapisovaným řádkem, například total_amount >= 0. PostgreSQL CHECK není určen k bezpečné kontrole dat v jiných řádcích či tabulkách.
Constraint a transakce
Pravidlo je vyhodnoceno v rámci zápisu a transakce; chrání tak proti části souběžných chyb, které validace předem nemůže vyřešit.
Vztah k podobným pojmům
Typ, validace a constraint se doplňují.
Žádná z vrstev sama nepokrývá všechny druhy pravidel.
- Databázový sloupec a datový typ
- Typ vymezuje druh hodnoty, constraint přidává další pravidlo integrity.
- Databázová transakce
- Drží související změny pohromadě, constraint kontroluje jejich povolený stav.
- Idempotence
- UNIQUE nad integrační identitou je častá ochrana proti duplicitnímu business efektu.
- Databázová migrace
- Přidává a mění constrainty verzovaně; nad nekonzistentními starými daty může změna selhat.
Výhody a omezení
Silnější data nejsou náhradou aplikačního návrhu.
Přínosy
- ochrana stavu při souběhu a více cestách zápisu
- invariant na jednom společném místě
- spolehlivější idempotence a referenční integrita
- dřívější odmítnutí nekonzistentního zápisu
Časté chyby
- spoléhání jen na validaci formuláře
- použití CHECK pro pravidlo závislé na externí službě
- nejasná databázová chyba ukázaná přímo uživateli
- příliš konkrétní pravidlo blokující budoucí proces
- předpoklad, že constraint automaticky řeší oprávnění nebo všechny business podmínky
Praktický příklad
Import marketplace objednávky
Objednávka má v daném marketplace jedinečné externí ID, nezápornou cenu, povinnou měnu a zákazníka. Aplikační služba může duplicitní import nejprve vyhledat, ale teprve UNIQUE constraint ochrání případ, kdy se dva workery pokusí zapsat tutéž zprávu současně.
Při porušení pravidla má aplikace poznat typ chyby a vrátit smysluplný výsledek. Databázový text chyby není vhodný přímo pro zákazníka ani pro odhalování interního schématu.
Na co myslet
Nejdřív pojmenujte pravidlo, potom zvolte jeho hranici.
Databázové omezení má být stabilní, srozumitelné a ověřitelné na existujících datech.
- validovat vstup pro uživatelskou zkušenost a constraintem chránit konečný stav
- zkontrolovat existující data před přidáním pravidla migrací
- rozlišit jedinečnost business údaje od primární identity
- nepoužívat CHECK pro vzdálený nebo rychle se měnící stav
- monitorovat a srozumitelně převádět porušení constraintů
Časté otázky
Constrainty v praxi
Proč nestačí validace v API?
Stejný zápis může přijít z importu, CLI, jiné služby nebo paralelního requestu. Databáze je společná poslední hranice integrity.
Je UNIQUE constraint totéž co primární klíč?
Ne. Primární klíč určuje hlavní identitu a nepřipouští NULL; UNIQUE může chránit další business identifikátor.
Patří každé business pravidlo do constraintu?
Ne. Constraint je vhodný pro stabilní pravidla nad databázovými daty. Pravidlo závislé na vzdálené službě, čase nebo složitém procesu patří obvykle do aplikační vrstvy.
Je výchozí hodnota constraint?
Ne. DEFAULT doplní hodnotu při vložení dat, ale sám nevyjadřuje ani nekontroluje širší pravidlo integrity.
Jak tento princip používám v praxi
Kritická pravidla ukládám i do databázového modelu.
Při návrhu e-commerce a integračních systémů kombinuji aplikační validaci s constrainty, transakcemi a dohledáním chyb v datech.