Volba mezi relační databází a flexibilním schématem není otázkou trendu, ale konkrétních požadavků na data. Relační model stojí na pevně definovaných tabulkách, sloupcích a typech. To zní jako omezení, dokud si neuvědomíte, že právě tato omezení drží data konzistentní. Pokud vaše aplikace pracuje s penězi, objednávkami, fakturami nebo čímkoli, kde nesmí vzniknout nekonzistentní stav, je relační databáze přirozenou volbou.

Flexibilní schéma dává smysl tam, kde se struktura dat mění každý týden, kde přicházejí polostrukturované dokumenty nebo kde potřebujete horizontální škálování za cenu slabších záruk. Jenže řada týmů skončí u dokumentové databáze jen proto, že se vyhýbá migracím. To je špatný důvod. Pokud si nejste jistí, jestli vaše data potřebují volnost, projděte si praktické rady o tom, kdy použít NoSQL, a porovnejte je s tím, co skutečně potřebujete. Často zjistíte, že transakce a cizí klíče vám ušetří víc práce než uvolněné schéma.

Relační databáze vyniká v dotazech napříč entitami. Když potřebujete spojit zákazníky, jejich objednávky a skladové položky do jednoho reportu, SQL je k tomu postavené. Agregace, filtrování, seskupování a joins zvládá bez ručního skládání dat v aplikaci. Flexibilní schéma naopak často nutí vývojáře psát logiku spojování do kódu, což se při růstu projektu mění v neudržovatelný problém. Databáze, která neumí join, není automaticky rychlejší, jen přesouvá odpovědnost jinam.

Dalším silným argumentem je integrita a souběžnost. Relační systémy nabízejí transakce s izolací, unikátní indexy a omezení na úrovni schématu. To znamená, že databáze sama odmítne nesmyslná data, místo aby spoléhala na to, že je aplikace nikdy nepošle. U flexibilních úložišť bývá validace dobrovolná a snadno se vynechá. Pokud tedy stavíte systém, kde chyba v datech znamená finanční nebo právní následky, relační databáze je bezpečnější základ. Flexibilní schéma použijte tam, kde převažuje rychlý vývoj a ochota obětovat část konzistence.