Volba mezi relační databází a NoSQL řešením není otázkou módnosti, ale konkrétních požadavků projektu. Řada českých týmů sáhne po NoSQL automaticky, protože zní moderně a slibuje horizontální škálování. Jenže špatně zvolený datový model se vrací jako technický dluh, který se opravuje měsíce. Rozhodnutí by mělo vycházet z povahy dat, konzistenčních nároků a způsobu, jakým se data budou dotazovat.

Relační databáze vyniká tam, kde potřebujete silnou konzistenci a složité vztahy mezi entitami. Transakce nad více tabulkami, cizí klíče, vynucené schéma a deklarativní dotazy v SQL jsou přesně ty vlastnosti, které u financí, fakturace, skladů nebo rezervačních systémů drží data v konzistentním stavu. Pokud se vaše dotazy během vývoje mění a potřebujete je skládat ad hoc, relační model s optimalizátorem dotazů vám dá mnohem větší svobodu než pevně definované přístupové cesty v NoSQL. Praktické zkušenosti s návrhem schématu a s tím, kdy se vyplatí denormalizace, najdete v článku na vyvojarska.cz, který pomáhá oddělit reálné přínosy od marketingových tvrzení.

NoSQL dává smysl ve chvíli, kdy objem dat přesahuje možnosti jednoho serveru, kdy je potřeba zapisovat stovky tisíc událostí za sekundu nebo kdy struktura dokumentů přirozeně odpovídá tomu, jak je aplikace čte a zapisuje. Typicky jde o logy, telemetrii, doporučovací modely nebo katalog produktů s velmi variabilními atributy. I tady ale platí, že bez jasné strategie pro konzistenci a bez plánu, jak řešit opravy nekonzistentních dat, se výhody rychle změní v provozní noční můru.

Pro české projekty se osvědčuje hybridní přístup. Transakční jádro systému zůstává v relační databázi, zatímco oddělené analytické nebo vyhledávací vrstvy běží na NoSQL. Rozhodujte se podle toho, jaké záruky potřebujete u čtení a zápisu, jak velký tým databázi spravuje a jestli máte kapacity na provoz distribuovaného clusteru. Když si tyto otázky zodpovíte předem, ušetříte si migraci, která se dělá mnohem hůř než volba na začátku.