---
title: "Návrh databáze: rozhodnutí, která se vymstí po dvou letech"
description: "Špatně navržená databáze se neprojeví hned. Projeví se tehdy, když je v ní půl milionu záznamů a každá změna znamená přepis poloviny aplikace."
canonical: "https://interfase.sk/cz/novinky/navrh-databaze-rozhodnuti-ktera-se-vymsti-po-dvou-letech"
lang: "cz"
last_updated: "2026-11-04"
---

# Návrh databáze: rozhodnutí, která se vymstí po dvou letech

> Špatně navržená databáze se neprojeví hned. Projeví se tehdy, když je v ní půl milionu záznamů a každá změna znamená přepis poloviny aplikace.

Publikováno: 2026-11-04

- Chyby v návrhu databáze se neprojeví u stovky záznamů, ale u statisíců — tehdy je oprava nejdražší.
- Záznamy, které něco znamenají pro historii, se nemažou, jen označují za neaktivní.
- Jedno pole má nést jednu informaci; kombinovaná pole se v budoucnu nedají filtrovat ani opravit.
- Cena na objednávce se ukládá k objednávce — odkaz na aktuální ceník znamená, že se staré doklady mění samy.

První rok je všechno v pořádku. Aplikace běží, data přibývají, nikdo si nestěžuje. Potom přijde požadavek, který zní triviálně — „chceme vidět, jak se objednávka měnila" — a odpověď je, že to nejde, protože ta informace nikdy nikde nebyla.

Toto je typický příběh návrhu databáze. Chyby v něm nebolí hned; bolí přesně tehdy, když je jejich oprava nejdražší.

## Nemažte, označujte

Nejčastější a nejdražší chyba. Smazaný zákazník vezme s sebou historii objednávek. Smazaný produkt udělá z faktur nesmysl. Smazaný uživatel znemožní odpovědět na otázku, kdo změnu udělal.

Pravidlo: **záznam, na který se něco odkazuje, se nemaže**. Označí se jako neaktivní a přestane se nabízet v nových operacích. Skutečné mazání se dělá jen tam, kde ho vyžaduje zákon — a tehdy cíleně, s vědomím, co se stane s vazbami.

Souvisí to s [auditem přístupů a bezpečnostními logy](/blog/audit-pristupov-a-bezpecnostne-logy-vo-firemnej-aplikacii): bez záznamu se nedá nic doložit.

## Aktuální stav není historie

Druhá klasická chyba je uložit jen to, jak věci vypadají teď. Sloupec `stav` s hodnotou „vyřízená" neřekne, kdy se to stalo ani přes které fáze objednávka prošla.

Pokud existuje byť jen tušení, že se někdy bude analyzovat průběh — a téměř vždy bude — patří k záznamu **historie změn stavu** jako samostatná tabulka. Doplňovat ji zpětně nelze, protože ta data neexistují.

## Cena patří k dokladu, ne do ceníku

Objednávka, která si tahá cenu z aktuálního ceníku, se po každé změně cen přepíše. Faktury z minulého roku najednou ukazují jiné částky než ty, které zákazník zaplatil.

Totéž platí pro adresy, sazby DPH, názvy produktů a podmínky. **Doklad je snímek stavu v čase svého vzniku** a ukládá si vlastní kopii všeho podstatného.

## Jedno pole, jedna informace

Pole `poznamka`, ve kterém jsou namíchané kontakty, sliby a interní komentáře, se po roce nedá ani prohledat, ani vyčistit. Totéž platí pro kombinace typu „jméno a příjmení v jednom sloupci" nebo „adresa jako jeden text".

Rozdělení se dělá snadno na začátku a těžko potom — u desetitisíců záznamů je to úloha na týdny a nikdy nevyjde bez chyb.

## Identifikátory a formáty

- **Nepoužívejte jako klíč něco, co se může změnit** — e-mail, IČO ani interní číslo. Lidé mění e-maily, firmy se slučují.
- **Číselné kódy s vedoucí nulou nejsou čísla.** PSČ a bankovní kódy patří do textu, jinak z „01234" bude „1234".
- **Čas ukládejte v UTC** a převádějte až při zobrazení. Přechod na letní čas jinak udělá z hodinových výkazů hádanku.
- **Peníze neukládejte jako desetinné číslo** s plovoucí čárkou. Zaokrouhlovací chyby se v součtech projeví.

## Rychlost je věcí návrhu, ne serveru

Aplikace, která je pomalá u statisíce záznamů, bývá pomalá kvůli chybějícím indexům a dotazům, které načítají víc, než potřebují. Silnější server to odloží o pár měsíců, nevyřeší.

Podrobněji jsme se tomu věnovali v článku o tom, [kde se ve firemní aplikaci reálně ztrácí čas](/blog/rychlost-firemnej-aplikacie-kde-sa-realne-straca-cas).

## Co dělat, když je už pozdě

Pokud aplikace běží a návrh je špatný, přepis celé databáze najednou není odpověď. Funguje postupný postup: **doplnit to, co chybí** (historie, příznak neaktivnosti, chybějící pole), **přestat mazat** a nové části stavět už správně. Rozdělení kombinovaných polí se dělá až tehdy, když je jasné, co v nich opravdu je.

## Kde začít

Dvěma otázkami: co se v naší databázi **maže** a **kde nemáme historii** tam, kde bychom ji chtěli. Odpovědi na ně bývají první seznam věcí, které se vyplatí opravit dřív, než dat přibude.

Pokud stavíte novou aplikaci nebo řešíte existující, [ozvěte se nám](/kontakt). Děláme to v rámci [vývoje na míru](/riesenia/vyvoj) — příklady v [referencích](/referencie).


---

Webová verze: https://interfase.sk/cz/novinky/navrh-databaze-rozhodnuti-ktera-se-vymsti-po-dvou-letech
llms.txt: https://interfase.sk/llms.txt