---
title: "Návrh databázy: rozhodnutia, ktoré sa vypomstia po dvoch rokoch"
description: "Zle navrhnutá databáza sa neprejaví hneď. Prejaví sa vtedy, keď je v nej pol milióna záznamov a každá zmena znamená prepis polovice aplikácie."
canonical: "https://interfase.sk/sk/novinky/navrh-databazy-rozhodnutia-ktore-sa-vypomstia-po-dvoch-rokoch"
lang: "sk"
last_updated: "2026-11-04"
---

# Návrh databázy: rozhodnutia, ktoré sa vypomstia po dvoch rokoch

> Zle navrhnutá databáza sa neprejaví hneď. Prejaví sa vtedy, keď je v nej pol milióna záznamov a každá zmena znamená prepis polovice aplikácie.

Publikované: 2026-11-04

- Chyby v návrhu databázy sa neprejavia pri stovke záznamov, ale pri státisícoch — vtedy je oprava najdrahšia.
- Záznamy, ktoré niečo znamenajú pre históriu, sa nemažú, len označujú za neaktívne.
- Jedno pole má niesť jednu informáciu; kombinované polia sa v budúcnosti nedajú filtrovať ani opraviť.
- Cena na objednávke sa ukladá k objednávke — odkaz na aktuálny cenník znamená, že sa staré doklady menia samy.

Prvý rok je všetko v poriadku. Aplikácia beží, dáta pribúdajú, nikto sa nesťažuje. Potom príde požiadavka, ktorá znie triviálne — „chceme vidieť, ako sa objednávka menila" — a odpoveď je, že sa to nedá, lebo tá informácia nikdy nikde nebola.

Toto je typický príbeh návrhu databázy. Chyby v ňom nebolia hneď; bolia presne vtedy, keď je ich oprava najdrahšia.

## Nemažte, označujte

Najčastejšia a najdrahšia chyba. Zmazaný zákazník zoberie so sebou históriu objednávok. Zmazaný produkt spraví z faktúr nezmysel. Zmazaný používateľ znemožní odpovedať na otázku, kto zmenu spravil.

Pravidlo: **záznam, na ktorý sa niečo odkazuje, sa nemaže**. Označí sa ako neaktívny a prestane sa ponúkať v nových operáciách. Skutočné mazanie sa robí len tam, kde ho vyžaduje zákon — a vtedy cielene, s vedomím, čo sa stane s väzbami.

Súvisí to s [auditom prístupov a bezpečnostnými logmi](/blog/audit-pristupov-a-bezpecnostne-logy-vo-firemnej-aplikacii): bez záznamu sa nedá nič doložiť.

## Aktuálny stav nie je história

Druhá klasická chyba je uložiť len to, ako veci vyzerajú teraz. Stĺpec `stav` s hodnotou „vybavená" nepovie, kedy sa to stalo ani cez ktoré fázy objednávka prešla.

Ak existuje čo i len tušenie, že sa niekedy bude analyzovať priebeh — a takmer vždy bude — patrí k záznamu **história zmien stavu** ako samostatná tabuľka. Dopĺňať ju spätne sa nedá, lebo tie údaje neexistujú.

## Cena patrí k dokladu, nie do cenníka

Objednávka, ktorá si ťahá cenu z aktuálneho cenníka, sa po každej zmene cien prepíše. Faktúry z minulého roka zrazu ukazujú iné sumy než tie, ktoré zákazník zaplatil.

To isté platí pre adresy, sadzby DPH, názvy produktov a podmienky. **Doklad je snímka stavu v čase svojho vzniku** a ukladá si vlastnú kópiu všetkého podstatného.

## Jedno pole, jedna informácia

Pole `poznamka`, v ktorom sú namiešané kontakty, sľuby a interné komentáre, sa po roku nedá ani prehľadať, ani vyčistiť. To isté platí pre kombinácie typu „meno a priezvisko v jednom stĺpci" alebo „adresa ako jeden text".

Rozdelenie sa robí ľahko na začiatku a ťažko potom — pri desaťtisícoch záznamov je to úloha na týždne a nikdy nevyjde bez chýb.

## Identifikátory a formáty

- **Nepoužívajte ako kľúč niečo, čo sa môže zmeniť** — e-mail, IČO ani interné číslo. Ľudia menia e-maily, firmy sa zlučujú.
- **Číselné kódy s vedúcou nulou nie sú čísla.** PSČ a bankové kódy patria do textu, inak z „01234" bude „1234".
- **Čas ukladajte v UTC** a prevádzajte až pri zobrazení. Prechod na letný čas inak spraví z hodinových výkazov hádanku.
- **Peniaze neukladajte ako desatinné číslo** s plávajúcou čiarkou. Zaokrúhľovacie chyby sa v súčtoch prejavia.

## Rýchlosť je vecou návrhu, nie servera

Aplikácia, ktorá je pomalá pri stotisíc záznamoch, býva pomalá kvôli chýbajúcim indexom a dotazom, ktoré načítavajú viac, než potrebujú. Silnejší server to odloží o pár mesiacov, nevyrieši.

Podrobnejšie sme sa tomu venovali v článku o tom, [kde sa v firemnej aplikácii reálne stráca čas](/blog/rychlost-firemnej-aplikacie-kde-sa-realne-straca-cas).

## Čo robiť, keď je už neskoro

Ak aplikácia beží a návrh je zlý, prepis celej databázy naraz nie je odpoveď. Funguje postupný postup: **doplniť to, čo chýba** (história, príznak neaktívnosti, chýbajúce polia), **prestať mazať** a nové časti stavať už správne. Rozdelenie kombinovaných polí sa robí až vtedy, keď je jasné, čo v nich naozaj je.

## Kde začať

Dvomi otázkami: čo sa v našej databáze **maže** a **kde nemáme históriu** tam, kde by sme ju chceli. Odpovede na ne bývajú prvý zoznam vecí, ktoré sa oplatí opraviť skôr, než dát pribudne.

Ak staviate novú aplikáciu alebo riešite existujúcu, [ozvite sa nám](/kontakt). Robíme to v rámci [vývoja na mieru](/riesenia/vyvoj) — príklady v [referenciách](/referencie).


---

Webová verzia: https://interfase.sk/sk/novinky/navrh-databazy-rozhodnutia-ktore-sa-vypomstia-po-dvoch-rokoch
llms.txt: https://interfase.sk/llms.txt