Normalizace databáze je jednou z posvátných krav vývoje aplikací. Každý kurz vysokoškolského programování, který jste absolvovali nebo který jste si přečetli, pravděpodobně káže důležitost normalizace databází. Je čas zpochybnit tento truismus. Někdy je v pořádku denormalizovat 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 jakékoli úsilí o návrh databáze byste měli začít s normalizací v mysli. Pokud můžete normalizovat svou databázi, jděte do toho! Závěrem je, že vy by měl normalizujte svou databázi, pokud nemáte opravdu dobrý důvod tak neučinit. Normalizace je obvykle zvuková designová praxe. 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 uložení stejných dat v různých rozích databáze.
Některé dobré důvody, proč se normalizovat
To znamená, že existuje několik dobrých důvodů pro nenormalizaci databáze. Podívejme se na několik:
- Spojení jsou drahá. Normalizace databáze často zahrnuje vytváření mnoha tabulek. Ve skutečnosti můžete snadno skončit s tím, co by podle vás mělo být jednoduchým dotazem, který pokrývá pět nebo 10 tabulek. Pokud jste se někdy pokusili udělat spojení pěti stolů, víte, že to funguje v zásadě, ale v praxi je to pečlivě pomalé. Pokud vytváříte webovou aplikaci, která se opírá o dotazy na více spojení proti velkým tabulkám, můžete si myslet: „Kdyby tato databáze nebyla normalizována!“ Když uslyšíte tuto myšlenku ve své hlavě, je vhodný čas zvážit denormalizaci. Pokud můžete vložit všechna data použitá tímto dotazem do jedné tabulky, aniž byste skutečně ohrozili integritu dat, jděte do toho! Staňte se rebelem a denormalizujte svou databázi. Neohlédneš se zpět!
- Normalizovaný design je obtížný. Pokud pracujete s komplexním databázovým schématem, pravděpodobně narazíte na to, že narazíte hlavou na stůl kvůli složitosti normalizace. Jako jednoduché pravidlo platí, že pokud trávíte celý den snahou přijít na to, jak přejít na čtvrtou normální formu, možná zabíráte normalizaci příliš daleko. Vraťte se a zeptejte se sami sebe, zda opravdu stojí za to pokračovat.
- Rychlý a špinavý by měl 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 design, 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, že ji možná budete muset vyhodit a začít znovu, až nastane čas stavět pro produkci.
- Pokud používáte databázi NoSQL, tradiční normalizace není žádoucí. Místo toho navrhněte svou 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.
Některá slova opatrnosti
Normalizace databáze je obecně dobrý nápad. Pokud se vám to zdá rozumné, měli byste se snažit dodržovat zásady normalizace. Pokud ale všechny ukazatele ukazují, že normalizace je příliš složitá na to, abyste ji mohli implementovat, zvažte přístup, díky kterému bude práce hotová, a přitom stále chrání vaše data. Nakonec – pokud se rozhodnete odchýlit se od pravidel normalizace, buďte zvlášť ostražití ohledně toho, jak vynucujete integritu databáze. Pokud ukládáte nadbytečné informace, vložte spouštěče a další ovládací prvky, abyste zajistili, že informace zůstanou konzistentní.