Slovník pojmů

Primární klíč

Primární klíč určuje identitu záznamu pro databázi a vztahy. Není to oprávnění k jeho zobrazení ani automaticky veřejný identifikátor.

Stručná definice

Jedna stabilní identita řádku.

Primární klíč označuje hlavní identitu řádku. Je užitečný pro aktualizace, mazání, cizí klíče i ORM, protože aplikace ví, na který záznam přesně míří. Tabulka má jeden primární klíč, ale může být složený z více sloupců.

V PostgreSQL primární klíč vynucuje jedinečnost i NOT NULL a pro něj vytváří unikátní B-tree index. To je konkrétní chování PostgreSQL; obecný návrh nemá předpokládat, že každá databáze má shodné implementační detaily.

Jaký problém řeší

Jednoznačné propojení a změny záznamů

Primární klíč brání tomu, aby aplikace upravila „nějakou podobnou“ objednávku místo konkrétního řádku.

identita objednávky, zákazníka, produktu či importu
cíl cizího klíče z položek objednávky
mapování identity entity v ORM
stabilní interní odkaz při změnách a auditu
rozlišení interního ID, veřejného UUID a externího marketplace ID

SQL ukázka

PostgreSQL: interní a business identity objednávky

Ukázka používá PostgreSQL identity sloupec. Primární klíč je id, ostatní jedinečné hodnoty chrání samostatná pravidla.

CREATE TABLE orders (
    id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    public_id uuid NOT NULL UNIQUE,
    marketplace_code text NOT NULL,
    external_order_id text NOT NULL,
    order_number text NOT NULL UNIQUE,
    UNIQUE (marketplace_code, external_order_id)
);

Jak funguje

Od vytvoření objednávky k jejím vazbám

Textová alternativa: primární klíč propojuje data; přístup ke konkrétní objednávce stále ověřuje autorizace.

Vznik objednávky Databáze vytvoří nebo přijme stabilní identitu, například číslo nebo UUID.
Jednoznačný řádek Primární klíč nedovolí uložit druhý řádek se stejnou hlavní identitou ani hodnotu NULL.
Navazující položky order_items.order_id může na primární klíč objednávky odkazovat cizím klíčem.
Další identity Číslo objednávky, veřejné UUID a externí ID mohou být samostatné unikátní business údaje.
Autorizace Server kromě nalezení ID kontroluje uživatele, tenant a oprávnění k operaci.

Důležité pojmy

Identita může mít několik rozumných podob.

Volba se řídí stabilitou hodnoty, vazbami, integracemi a způsobem publikování.

Jednoduchý a složený klíč

Jednoduchý klíč je jeden sloupec. Složený klíč obsahuje více sloupců, například dvojici order_id a product_id ve spojovací tabulce.

Přirozený a umělý klíč

Přirozený klíč existuje v doméně, například stabilní kód. Umělý neboli surrogate klíč je technická identita. Žádný není univerzálně lepší.

Sekvence a UUID

Sekvenční integer se jednoduše generuje. UUID může být vhodný pro distribuované vytváření nebo veřejné adresy, ale sám neřeší autorizaci.

Unikátní constraint

Tabulka smí mít více unikátních pravidel, ale jen jeden primární klíč. Unikátní business kód proto nemusí být hlavní identitou.

ORM identita

ORM pracuje s identitou entity, ale nenahrazuje databázový constraint ani rozhodnutí, který údaj je stabilní.

Vztah k podobným pojmům

Klíč, business údaj a přístup jsou odlišné vrstvy.

Jedno ID může mít technickou, veřejnou i integrační roli, které je vhodné nerozmělňovat.

Cizí klíč: Odkazuje na primární nebo jiný vhodný unikátní klíč a chrání referenční integritu.
Databázový constraint: PRIMARY KEY je jeden z constraintů a prohlásí hlavní identitu řádku.
Databázový index: V PostgreSQL se pro primární klíč vytvoří unikátní index; index ale není sám o sobě autorizace.
Doctrine ORM: Mapuje identitu entity, pracuje však nad databázovou identitou a jejími pravidly.

Výhody a omezení

Správná identita není bezpečnostní hranice.

Přínosy

jednoznačné cílení update a delete
bezpečný cíl pro vztahy mezi tabulkami
jasná dokumentace hlavní identity modelu
podpora ORM a konzistentních importů

Časté chyby

tvrzení, že primární klíč musí být autoincrement číslo
použití měnícího se business údaje jako neměnné identity
považování UUID za autorizaci nebo ochranu dat
vystavení sekvenčního ID bez zvážení informačního úniku
nepromyšlený složený klíč, který se propíše do všech vztahů

Praktický příklad

Jedna objednávka, čtyři odlišné identifikátory

Objednávka může mít interní primární klíč id, veřejné public_id typu UUID, order_number pro obchodní komunikaci a dvojici marketplace_code plus external_order_id pro idempotentní import. Každý údaj má jiný účel; není nutné z nich uměle dělat tutéž hodnotu.

Pokud se veřejné UUID dostane do URL, server stále ověřuje, zda na objednávku smí nahlížet přihlášená identita v konkrétním tenantovi.

Na co myslet

Zvolte identitu podle stability a role.

Klíč se časem propíše do vazeb, migrací, API a reportů, proto má být jeho význam explicitní.

rozlišit technickou identitu, veřejný odkaz a integrační business identifikátor
použít UNIQUE pro další jedinečné údaje
u složeného klíče zhodnotit dopad na všechny navazující cizí klíče
neodvozovat oprávnění pouze z toho, že klient zná ID
zohlednit přístupové vzory a indexy při volbě generování identity

Časté otázky

Primární identita v praxi

Musí být primární klíč autoincrement?

Ne. Může to být UUID, přirozená stabilní hodnota nebo složená kombinace sloupců.

Může tabulka mít více primárních klíčů?

Ne. Má jeden primární klíč, který ovšem může obsahovat více sloupců. Další jedinečné údaje chrání UNIQUE constrainty.

Je číslo objednávky vhodný primární klíč?

Jen pokud je dlouhodobě neměnné a odpovídá potřebám modelu. Často je výhodnější samostatný technický klíč a číslo objednávky jako unikátní business údaj.

Chrání UUID před čtením cizí objednávky?

Ne. Neodhadnutelný identifikátor nenahrazuje serverovou kontrolu autorizace.

Jak tento princip používám v praxi

Identity odděluji podle jejich skutečného účelu.

V e-commerce a integracích řeším interní, veřejné i externí identifikátory spolu s databázovými pravidly pro bezpečné změny a retry.

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