Normalizace vs. Denormalizace databází

Normalizace databáze je jednou z posvátných krav vývoje aplikací. Každý vysokoškolský kurz programování, který jste absolvovali nebo kniha, kterou jste si přečetli, pravděpodobně káže důležitost normalizace databází.

Je čas zpochybnit tuto pravdu. Někdy je v pořádku denormalizovat svou databázi!

Kdy byste se měli normalizovat?

Normalizace databáze chrání integritu vašich dat. V mnoha případech je to skvělý nápad a měli byste začít jakékoli úsilí o návrh databáze s ohledem na normalizaci. Pokud můžete normalizovat svou databázi, jděte do toho!

Pointa je, že vy by měl normalizujte svou databázi, pokud nemáte opravdu dobrý důvod to neudělat. Normalizace je obvykle praxe zdravého designu. Snižuje nadbytečné informace, optimalizuje výkon a snižuje pravděpodobnost, že budete mít problémy s integritou dat, které vyplývají z toho, že stejná data jsou uložena v různých koutech vašeho počítače databáze.

Několik dobrých důvodů, proč se nenormalizovat

To znamená, že existuje několik dobrých důvodů, proč svou databázi nenormalizovat. Podívejme se na několik:

1. Spojení jsou drahá. Normalizace databáze často zahrnuje vytvoření velkého množství tabulek. Ve skutečnosti můžete snadno skončit s tím, co si myslíte, že by měl být jednoduchý dotaz, který zahrnuje pět nebo 10 tabulek. Pokud jste někdy zkusili spojení s pěti stoly, víte, že to v principu funguje, ale v praxi je to pracně pomalé. Pokud vytváříte webovou aplikaci, která se spoléhá na dotazy s vícenásobným spojením proti velkým tabulkám, možná se ocitnete pomyslel si: "Kdyby tato databáze nebyla normalizována!" Když uslyšíte tuto myšlenku ve své hlavě, je to dobrý čas na zamyšlení denormalizace. Pokud můžete všechna data použitá tímto dotazem vložit do jediné tabulky, aniž byste skutečně ohrozili integritu dat, jděte do toho! Buďte rebel a denormalizujte svou databázi. Nebudeš se ohlížet!
2. Normalizovaný design je obtížný. Pokud pracujete se složitou databází schéma, pravděpodobně zjistíte, že budete mlátit hlavou do stolu nad složitostí normalizace. Jednoduše řečeno, pokud trávíte celý den snahou přijít na to, jak přejít do čtvrté normální formy, možná zacházíte s normalizací příliš daleko. Udělejte krok zpět a zeptejte se sami sebe, zda opravdu stojí za to pokračovat.
3. Rychle a špinavě by mělo být rychlé a špinavé. Pokud právě vyvíjíte prototyp, udělejte vše, co funguje rychle. Opravdu. To je v pořádku. Rychlý vývoj aplikací je někdy důležitější než elegantní design. Nezapomeňte se vrátit a pečlivě se podívat na svůj návrh, jakmile budete připraveni přejít za fázi prototypování. Cena, kterou zaplatíte za rychlý a špinavý návrh databáze, je ta, že ji možná budete muset zahodit a začít znovu, až přijde čas na sestavení pro produkci.
4. Pokud používáte databázi NoSQL, tradiční normalizace není žádoucí. Místo toho navrhněte databázi pomocí modelu BASE, který je mnohem shovívavější. To je užitečné, když ukládáte nestrukturovaná data, jako jsou e-maily, obrázky nebo videa.

Pár slov opatrnosti

Normalizace databáze je obecně dobrý nápad. Měli byste se pokusit dodržovat zásady normalizace, když se vám to zdá rozumné. Pokud však všechny indikátory naznačují, že normalizace je příliš složitá na to, aby ji bylo možné implementovat, zvažte přístup, který provede práci a zároveň ochrání vaše data.

A konečně – pokud se rozhodnete odchýlit se od pravidel normalizace, buďte zvlášť opatrní při prosazování integrity databáze. Pokud ukládáte nadbytečné informace, umístěte spouštěče a další ovládací prvky, abyste zajistili, že informace zůstanou konzistentní.