SQL vs NoSQL: která databáze se hodí vaší aplikaci?

SQL databáze (označované také jako relační databáze) ukládají data do tabulek s definovanou strukturou — řádků a sloupců — a propojují související tabulky. Dotazujete se na ně jazykem SQL. Příklady jsou Postgres, MySQL a SQLite. NoSQL databáze ukládají data jinými způsoby — dokumenty, páry klíč-hodnota, široké sloupce nebo grafy — a obvykle umožňují pružnější strukturu. Příklady jsou MongoDB, Redis, DynamoDB a Firestore. Pro většinu firemních aplikací je SQL databáze rozumnou výchozí volbou; NoSQL vyniká u specifických úloh.

Proč na této volbě záleží při tvorbě s AI

Databáze patří mezi nejtěžší části aplikace na pozdější změnu. Obrazovky lze přepracovat za odpoledne; přesun let zákaznických dat do jiného typu databáze je projekt.

Když AI tvůrce aplikací přidá úložiště dat za vás, vybírá jednu z těchto možností. Znalost rozdílů vám pomůže:

• Pochopit, jak vypadají vaše data a zda na ně půjde odpovědět otázky, které budete chtít položit později („tržby podle měsíce a produktu“).
• Posoudit volbu platformy. Některé platformy stojí na dokumentové databázi, jiné na relační. Běžným příkladem obou je srovnání Supabase vs Firebase.
• Vyhnout se vendor lock-inu. SQL je sdílený standard, takže relační data se obvykle snadněji přenášejí mezi poskytovateli.

Každodenní přirovnání

SQL databáze je jako soubor pečlivě navržených tabulek s přísnými sloupci: jeden list pro zákazníky, jeden pro objednávky, a každý řádek objednávky odkazuje na řádek zákazníka pomocí ID. Každý řádek v listu má stejné sloupce. Chvíli to vyžaduje plánování, ale položit otázku napříč listy je snadné a data zůstávají uspořádaná.

NoSQL dokumentová databáze je jako kartotéka složek. Složka každého zákazníka může obsahovat jeho údaje i objednávky najednou a jedna složka může obsahovat dodatečné papíry, které jiné nemají. Získat celý příběh jednoho zákazníka je rychlé. Odpovědět na otázku „co si všichni objednali minulý měsíc?“ znamená otevřít spoustu složek.

Skutečné rozdíly

„NoSQL“ není jedna věc. Hlavní druhy jsou:

Pracovní příklad: stejná data obchodu dvěma způsoby

Vezměme malý online obchod se zákaznicí a jejími objednávkami.

SQL (relační): data jsou rozdělena do tabulek a propojena ID.

-- customers: id=1, name='Lena Ortiz'
-- orders:    id=101, customer_id=1, total=42.00
--            id=103, customer_id=1, total=25.00

SELECT c.name, SUM(o.total)
FROM customers c JOIN orders o ON o.customer_id = c.id
GROUP BY c.name;

Když Lena změní e-mail, změní se na jednom místě. Otázka „celkové tržby na zákazníka tento měsíc“ je jeden dotaz.

NoSQL (dokument): její objednávky mohou být uvnitř jejího dokumentu.

{
  "_id": "cust_1",
  "name": "Lena Ortiz",
  "email": "lena@example.com",
  "orders": [
    { "id": 101, "total": 42.00, "items": ["Zelený čaj"] },
    { "id": 103, "total": 25.00, "items": ["Konvice na čaj"] }
  ]
}

Načtení profilové stránky Leny se všemi jejími objednávkami je jedno čtení. Dotazy přes všechny zákazníky — nejprodávanější produkt tento měsíc — ale vyžadují více práce, a pokud se stejné údaje o produktu kopírují do mnoha objednávek, jejich udržování v souladu se stává úkolem aplikace.

Žádná z variant není špatná. Otázka zní, který vzor vaše aplikace používá nejčastěji.

Jak vybrat

Relační SQL databáze je obvykle správnou výchozí volbou, pokud:

• Vaše data mají hodně vztahů: uživatelé, týmy, rezervace, faktury, produkty.
• Budete potřebovat reporty, filtry a součty napříč záznamy.
• Záleží na správnosti: peníze, stavy skladu, oprávnění.

NoSQL databázi stojí za zvážení, pokud:

• Potřebujete rychlou cache nebo úložiště relací — zde je běžný Redis, často vedle SQL databáze.
• Vaše záznamy jsou v obrovském počtu, jednoduché a nezávislé, jako logy událostí nebo údaje ze senzorů.
• Jste na platformě postavené na některé z nich, například na Firestore od Firebase, a jejím hlavním lákadlem jsou funkce v reálném čase.

Mnoho aplikací používá obojí: SQL jako hlavní zdroj pravdy a NoSQL úložiště pro cache nebo konkrétní funkci.

Klíčové pojmy

Časté omyly

• „NoSQL znamená žádné schéma.“ Vaše data vždy nějaký tvar mají. U NoSQL databáze jej nemusí vynucovat, takže to musí dělat váš kód.
• „SQL se neškáluje.“ Relační databáze provozují velmi velké služby. Většina aplikací se jejich limitů ani nepřiblíží.
• „NoSQL je vždy rychlejší.“ Jen pro vzory, pro které je navržen. Průřezový report může být pomalejší.
• „Musíte se navždy rozhodnout pro jednu.“ Mnoho aplikací kombinuje obojí. A SQL databáze jako Postgres ukládají i JSON, takže několik pružných polí nevyžaduje NoSQL.
• „NoSQL znamená, že nemůžete používat SQL.“ Název se obvykle chápe jako „nejen SQL“ a některé NoSQL produkty nabízejí dotazovací jazyky podobné SQL.

Na co se zeptat svého AI tvůrce

• „Jakou databázi tato aplikace používá a proč se hodí k mým datům?“
• „Nakreslete tabulky nebo kolekce a jak spolu souvisejí.“
• „Které reporty budu chtít za šest měsíců? Dokáže na ně tato databáze snadno odpovědět?“
• „Pokud je několik polí opravdu pružných, ukládejte je jako JSON v Postgresu, namísto přidání druhé databáze.“
• „Přidejte cache, jen pokud máme změřený problém s rychlostí.“

Databáze v Mythexu

Mythex dává každému projektu, který ji potřebuje, vlastní Postgres databázi — relační SQL databázi — přidanou ve chvíli, kdy ji aplikace potřebuje, buď dotazem v chatu, nebo příkazem /database (Database). To vyhovuje většině firemních aplikací: uživatelé, rezervace, objednávky a reporty. Pokud potřebujete konkrétní externí službu, například hostovanou dokumentovou databázi, může agent napsat kód, který se k ní připojí pomocí klíčů uložených jako tajemství projektu. Více o samotném jazyku se dozvíte v článku co je SQL.

Otázky