JOIN (spojení)

Příklady z praxe

1. 01

   Objednávky s e-mailem zákazníka

   E-shop potřebuje vypsat objednávky společně s e-mailem zákazníka. INNER JOIN vrátí jen objednávky, které mají odpovídající záznam v tabulce customers. Objednávka s poškozeným customer_id se do výsledku nedostane, což může být žádoucí pro čistý export, ale nevhodné pro audit chyb.

   SELECT o.id, o.created_at, c.email
   FROM orders AS o
   INNER JOIN customers AS c
     ON c.id = o.customer_id;

2. 02

   Produkty bez kategorie

   Správce katalogu hledá produkty, kterým chybí platná kategorie. LEFT JOIN zachová všechny produkty a u produktů bez shody v categories doplní NULL. Podmínka ve WHERE pak vybere právě problematické položky, které by INNER JOIN úplně skryl.

   SELECT p.id, p.name, c.name AS category_name
   FROM products AS p
   LEFT JOIN categories AS c
     ON c.id = p.category_id
   WHERE c.id IS NULL;

Časté omyly

MýtusJOIN jen přidá sloupce z druhé tabulky.

Ve skutečnostiJOIN může přidat sloupce, ale současně může filtrovat nebo násobit řádky podle počtu shod. Výsledek závisí na typu JOINu a podmínce v ON.

MýtusLEFT JOIN je vždy bezpečnější než INNER JOIN.

Ve skutečnostiLEFT JOIN zachová nespárované řádky z levé tabulky, ale tím může do výsledku dostat NULL hodnoty a změnit význam filtrů. INNER JOIN je správnější, pokud dotaz vyžaduje existující shodu.

MýtusIndex na cizím klíči vždy vyřeší pomalý JOIN.

Ve skutečnostiIndex často pomůže, ale výkon JOINu závisí také na velikosti tabulek, selektivitě, filtrech, statistikách a tvaru dotazu. Plán dotazu je spolehlivější vodítko než samotná existence indexu.

Časté dotazy

Kdy má JOIN zůstat v databázi místo ve zdrojovém kódu aplikace?

JOIN obvykle patří do databázového dotazu, když aplikace potřebuje konzistentní data z více tabulek a spojení lze vyjádřit jasnou relační podmínkou. Spojování v aplikaci může dávat smysl u malých doplňkových seznamů, cache nebo dat z různých systémů. Databáze však často zvládne filtrování, spojení a agregaci efektivněji, protože má statistiky, indexy a optimalizátor dotazů.

Proč je některý JOIN v SQL pomalý?

JOIN sám o sobě nemusí být pomalý. Pomalost obvykle vzniká z velkého objemu dat, chybějících nebo nevhodných indexů, nepřesných statistik, špatné spojovací podmínky nebo z dotazu, který vrací víc řádků, než aplikace potřebuje. Pro posouzení výkonu je důležitý plán dotazu, protože databáze může použít různé strategie spojení podle konkrétních tabulek a filtrů.

Kdy použít LEFT JOIN místo INNER JOINu?

LEFT JOIN je vhodný, když výsledek musí obsahovat všechny řádky z první tabulky bez ohledu na to, zda existuje odpovídající řádek ve druhé tabulce. Typický případ je seznam produktů včetně volitelné kategorie nebo kontrola objednávek bez platného zákazníka. INNER JOIN by nespárované řádky odstranil, takže by mohl skrýt právě ta data, která chce dotaz odhalit.

Proč JOIN vrací více řádků než původní tabulka?

JOIN může změnit počet řádků, protože jedna shoda na levé straně může odpovídat více řádkům na pravé straně. Zákazník se třemi objednávkami se po spojení se seznamem objednávek objeví třikrát. Výsledek není chyba, pokud dotaz pracuje s objednávkami, ale při počítání zákazníků je potřeba agregovat opatrně a často použít DISTINCT nebo seskupení.

Zdroje

1. 7.2. Table Expressions(otevře se v novém okně)PostgreSQL Global Development Group
2. SELECT(otevře se v novém okně)SQLite
3. Joins(otevře se v novém okně)Microsoft

Související pojmy

• IndexIndex je pomocná datová struktura, která databázi umožní najít řádky podle hodnoty sloupce bez procházení celé tabulky. Zrychluje čtení, zpomaluje zápis a zabírá místo, takže každý index je vědomý kompromis.
• Normalizace databázeNormalizace databáze je způsob návrhu relační databáze, při kterém se data rozdělují do tabulek podle významu a závislostí, aby se omezila duplicita a nekonzistence. Typicky se opírá o normální formy, primární klíče a cizí klíče; výsledkem je čistší model, ale někdy složitější dotazy.
• SQLSQL je deklarativní jazyk pro práci s relačními databázemi, ve kterém se popisuje, jaká data chce uživatel vybrat, změnit nebo definovat, nikoli přesný postup jejich získání. Používá se pro dotazy, vkládání, aktualizace, mazání, tvorbu tabulek, oprávnění i transakční zpracování v mnoha databázových systémech.
• Cizí klíčCizí klíč je databázové omezení, které ukládá, že hodnota ve sloupci nebo skupině sloupců musí odpovídat existujícímu řádku v jiné, případně téže tabulce. Relační databáze tím chrání vazby mezi záznamy, například aby objednávka neodkazovala na neexistujícího zákazníka a data zůstala konzistentní.
• Dotazovací plánDotazovací plán je postup kroků, kterým databáze skutečně vykoná zadaný SQL dotaz: v jakém pořadí čte tabulky, zda použije index nebo sekvenční průchod a jakou metodou spojí data. Plán sestavuje plánovač na základě statistik o datech a vybírá z více možností tu s nejnižší odhadovanou cenou.
• DenormalizaceDenormalizace je záměrné zavedení redundance do datového modelu, typicky zkopírováním nebo předpočítáním hodnot z jiných tabulek, aby čtení nemuselo spojovat mnoho tabulek a agregovat je za běhu. Denormalizace zrychluje dotazy výměnou za větší objem dat, složitější zápisy a riziko, že se kopie hodnoty rozejdou s originálem.
• A/B testováníA/B testování je řízený experiment, který porovnává dvě varianty stránky, funkce, ceny nebo sdělení na podobných skupinách uživatelů. Měří předem zvolenou metriku, například konverzi nebo retenci, a pomáhá rozhodnout, zda změna skutečně zlepšuje výsledek, nebo zda pozorovaný rozdíl mohl vzniknout náhodou.
• ACIDACID je sada čtyř vlastností databázové transakce: atomicity, consistency, isolation a durability. Zaručuje, že skupina zápisů proběhne jako jeden celek, neporuší definovaná pravidla databáze, nebude se nebezpečně míchat s jinými transakcemi a po potvrzení přežije pád systému, například při převodu peněz.