Názory k článku [ ( LEFT|RIGHT [ OUTER ])| INNER ] JOIN v SQL

Clovek zvladne SQL az kdyz pochopi:

0. jak kodovat kvalitni obsluhu chyb v Oraclu vcetne race conditions. Typicky
priklad je nechat nakodovat dilema insert or update
1. writeable cursory a jejich problemy
2. isolation levely + zamykani
3. dist. transakce vcetne recovery mechanizmu

Programatori nemaji s joiny moc problem. Ale pokud neumi tyhle veci, tak jsou nepouzitelni pro kazdy projekt kde zalezi na integrite dat. Ackoliv to neni zadna high technologie vetsina co se mi hlasi na to nema, nechce se to ucit, radsi si najde jine misto, je s tim mene prace.

tohle neni potreba vubec znat, na tohleto jsou uz dneska nastroje, ktere to udelaji mnohem lepe nez clovek. Mockrat jsem to testoval.

Pravda, tyhle high-end nastroje nejsou zrovna nejlevnejsi ale nahrazuji hodne lidske prace, takze ROI to ma.

No dovolim si nesouhlasit. Kdyz spravujete DB o velikosti pouhych 1-2 TB a jede ciste v OLTP rezimu se 4 tisici concurrent sessions, tak jsou to sakra dulezite veci...

S tím si dovolím nesouhlasit. To jsou hodně specifické záležitosti jak pro Oracle, tak pro konkrétní aplikace. Třeba kurzorům je lepší se vyhnout. Samozřejmě, pokud se přepisují 30 let staré aplikace, tak to moc dobře nejde, a taky to je důvod, proč se kurzory do SQL přidaly - jinak tam nemají co dělat. Ne, že by to nebylo důležité, ale jádro SQL vidím jinde a to v operacích s relacemi. Navíc mám jinou zkušenost. Skutečně pro řadu programátorů je JOIN problém. Ti, co řeší isolation levely, už jsou opět někde jinde.

SQL není pouze PL/SQL. Se staršími verzemi Oraclu jsem nikdy nedělal, takže nevím,jestli tam kurzory byly od samého počátku nebo ne. Ale třeba u MSSQL se kurzory přidávali. A v samotném SQL, coby jazyku, je úloha kurzorů docela podružná a redundantní (původně kurzory byly implementační záležitostí). Prostě kurzory v SQL jsou taková diskutabilní a kontroverzní záležitost.

To taky netvrdím, a ve článku několikrát zdůrazňuji, že záleží na datech, db stroji, indexech, úloze, aplikaci, zatížení. Ale budu tvrdit, že bez znalosti standardu, coby jazyka, těžko budete psát optimální selecty kdekoliv. A zase je otázkou, co je optimální. Jinak bude vypadat optimální dotaz v aplikaci s 10K uživateli a jinak v aplikaci s 10 uživateli, pokud jako jedno z kritérii budu náklady na programátora. V aplikaci s tisícem uživatelů se musíte s časy dostat na desítky milisekund. Pokud máte desítky uživatelů tak tam časy v řádech stovek milisekund až tak nevadí. Prioritou je znalost jazyka. Bez ní je to bastlířina. Sekundární je znalost konkrétního stroje. Bez ní je to alchymie.

Rekl bych ze to jsou vsechny projekty kde jejich vlastnik nebo designer pochopil ze data jsou ta nejcenejsi deviza. Tyto projekty se v soucasne dobe typicky poznaji podle toho, ze nejedou na MySQL.

A nyni uz dalsi cilso tolik oblibeneho MySQL bulletinu!
transakce? to se dela na aplikacni urovni. Spravny programator to nakodi.
joiny? To se dela na aplikacni urovni taky
foreign klice? To jako myslite tu vec co brzdila Oracle7 o 100% pri updatech? Jasnacka, syntax podporujeme
nejake normy? bah, overrated. I kdyz pravda v 5.0 jsme prekodovali joiny tak, aby konecne vracely spravna data aletovite customeri si stezuji ze jim to rozbilo aplikace, tak v 6.0 to zase vratime nazpet.
NULL hodnoty? bah, kazde male dite prece vi ze misto NULLu chytre databaze mysli za kodera a ukladaji DEFAULT hodnotu
chcete vladat retezce do integer sloupcu? U nas muzete!
Prodluzte si s nami dovolenou, jen u nas ma unor 31dnu!
Kdyz zhavaruje tabulka MYISAM garantujeme ze neprijdete vice nez o 1% ulozenych dat.
Pravda v innodb mame jeste nejake races, takze recovery nekdy vyhnije. Proste si od nas kupte nas replikacni software.
Rollfoward recovery? To myslite tu zbytecnost z Oraclu5? Proc je ten Oracle tak nemoznej a porad implementuje veci co brzdi databazi! Podivejte se na nase benchmarky, jsme 10x rychlejsi!
Neztracejte cas s testovanim navratovych hodnot! Pro lepsi efektivitu programatora pro vas mame pripravene prikazy INSERT DELAYED a INSERT LOW PRIORITY
Triggery a primary klice? To myslite, ty viry co vam zabranuji manipulovat s daty jak se vam zlibi? Uznavame, to musi uz jednou prestat a proto jsme pro vas pripravili .... INSERT IGNORE!
Musime vam s politovanim oznamit, ze jsme byli nuceni zrusit podporu elastickych tabulek a tim padem i vami tak oblibene syntaxe INSERT INTO tbl_name (a,b,c) VALUES(1,2,3,4,5,6,7,8,9); Fakt nas to mrzi, ale porad nekteri idioti do toho vrtali a rvali na nas SQL92!
Radi bychom vam predstavili taky nase skvele insert/update kombo INSERT INTO ... ON DUPLICATE KEY UPDATE x=x+1; Tento prikaz vam umozni rychle updatovat vase tablice. Proto jsme ho pochopitelne nakodili. Narozdil od ostatnich nasich prikazu, ktere jsou taky rychle jen tento uber rychly! Je tak rychly, ze se provede driv nez to nase replikace vubec zaznamena. Jeho pouzitim doslova predbehnete dobu! Jeho pouziti doporucujeme zejmena v aplikacich, kde je dulezita rychlost, napriklad pri zpracovani plateb kreditkou.
Prestante uz konecne resit nejake row level/ block level locking ci MVCC. Radi bychom vam predstavili nase vysoce kvalitni zamky.
Nase zamky nejsou zadni drobeckove u nas se netroskari - zamykame cele tabulky a vase data tak budou pred ostatnimy uzivateli v bezpeci.
My svou praci neodbyvame, kdyz neco zamkneme, tak to drzi! Nase zamky drzi lepe i nez vase connection. Kdyz tam spadne, nebojte se, nas zamek bude drzet dal, na to vemte jed.

Integrita dat je spatna pro vas byznys! S vyuzitim spravne databaze spojene s kvalitnim koderem a nasim e-shop produktem muzete bez problemu koupit 10 vyrobku a prodat jich 12! Tim vydelate 20%! Uvedomte si, ze jsou to penize, ktere vam padaji z nebe diky nasim kvalitnim a rychlym technologiim!

kdybych mysql5.0 nepouzival pro nektere lidi co ji vyzaduji (support mysql prodavame 3x draze nez support oraclu, pac vyzaduje vice lidske prace na zajisteni stejneho service levelu. napriklad neustale kontroly zda se data replikuji spravne), tezko bych vedel takovyto seznam jejich bugu a navic by mne byla uplne ukradena jako ostatni produkty ktery nepouzivam - je mi uplne fuk, zda tam jsou bugy ci ne.

Jinak nejlevnejsi Oracle stoji $5K a nejlevnejsi DB/2 stoji $3k. Ta DB/2 umi v teto verzi narozdil od Oraclu i HA fce t.j. failover/replikaci. To je tolik, co si nekdo nemuze dovolit zaplatit pro produkcni nasazeni? Spocitejte si jen naklady na administraci DB serveru rekneme za 5 let, kolik $$ stoji napriklad jen plat administratora. Pak poznate, ze napriklad ta cena DB/2 je jen kapka v mori.

Krom toho muzete mit dneska uz DB/2 zdarma a to i pro produkcni nasazeni (bez replikace/failoveru). DB/2 ale umi online backup, rollforward recovery a to se da pouzit misto builtin failoveru. DB/2 je databaze v tride s Oraclem.

http://www-306.ibm.com/software/data/db2/express/

Nepovazuji toho, kdo nepouziva Oracle za lamu, sam mam v produkci i pgsql a DB/2. Nainstalujte demo Oracle ci DB/2 otestujte poradne proceduralni jazyky, replikaci a autotuning db pak pochopite.

No právě. Pochopil bych, že někdo používá sw, který šetří práci a nevyžaduje elitní programátory. Proč ale používat sw, který práci nešetří?

Ty veci co jsem nastinil jsou vysvetleny velmi podrobne ve VS skriptech ktere mi tu lezi na stole. V zadnem pripade se nejedna o highend, ke kteremu se dobereme horkotezko dlouholetou praxi. Jedna se o zaklad, ktery se vyucuje na VS.

Je mi jasne ze nejen studenti, ale i vetsina SQL coderu co se sem hlasi o tom nema ani paru. Nikdy o tom neslyseli a ani nechapou proc by se to vlastne melo delat. Protoze je urovne ceskeho IT takova jaka je, mame proto tyto zakladni veci najednou prohlasovat za highend abychom zamaskovali svou neznalost? Prestanme si laskave toto nalhavat. Co budeme pokladat za highend priste? Referencni integritu? Triggery? Transakce?

a prestante mi tu machrovat s prachama. O tom to vubec neni. Budto to znate nebo ne. Jenom hlupaci argumentuji stylem: Prace kterou jsem odvedl je sice zprasena, ale to je tim, ze za to mam malo (nebo nic, kdyz se jedna o open source).

Jaky kdyby hudebni mistr hral jak prase kdyz bude hrat nekomu pro radost. Kdyz umite dobre hrat, tak to umite vzdycky. S programovanim je to stejne.

normalizace dat je taky napytel, je to sice napohled hezke a vseobecne uznavano jako dobry design. Ale kdyz mate velke tabulky tak si zatracene rychle zacnete uvedomovat jak pridani kazde dalsi tabulky do selectu brzdi.

Dnes neni zadny duvod pro normalizaci za kazdou cenu. Mista na disku a v pameti je vice nez dost a sekvencni pristup je rychly.

Sekvencni nacitani denormalizovane tabulky je mnohem rychlejsi nez behani po 3 ruznych tabulkach soucasne. Sekvencni cteni je minimalne 5-8x rychlejsi nez nahodny pristup a dnesni storage servery umi z pole sekvencne cist 2GBajty/sec. Pod pojmem storage server nemyslim zadny uber highend, ale nic zvlastniho bezne pouzivany stroj za cca $35K s rekneme 50ti lowend sata disky. Storage server s SAS 15k rpm disky ma podstatne lepsi prujezd, tomu taky odpovida cena.

Zkuste si auditovat pár shopů jako já a zjistíte, že to není pravda. Sekvenční čtení je samozřejmě rychlejší, mimochodem sekvenční čtení se použije i když spojujete tabulky, ale má jeden dost nepříjemný důsledek. Dost Vám zacloumá s cache. Přístup do denormalizovaných tabulek není tak častý (většinou se jedná o analýzy, reporty) a je mnohem efektivnější použít OLAP nebo materializované tabulky. Docela dost se setkávám s tím, že místo toho, aby ve firmě nasadili OLAP, tak právě vymýšlejí takovéto brikule. Tím problém nevyřeší, a ještě mají problém s hw. Hlavní důvod pro normalizaci je dekompozice dat. Pokud máte dobře dekomponovaná data, budou se dobře psát selecty. Pokud máte denormalizovaná data, pak v podstatě používáte SQL jen jako data storage, a vlastně SQL Vám je spíš na škodu než k užitku.

Protože je UNION úplně něco jiného (a zase téma na celý článek).

My jsme jednou na Oraclu (9i) narazili na to, že dotazy s vnorenymi dotazy obsahujicimi linky do jinych databazi to pri vyuziti JOINove syntaxe vyhodnocovalo velmi neefektivne (select bezel i hodiny aby pak spadla na rollback segment too small) a i hinty to ignorovalo. Mistni DBA nam poradili prevod do ,WHERE syntaxe (pri zachovani stejne logiky), coz vyrazne pomohlo a jeste se to pak dalo trochu urychlit pomoci hintu.

To je asi právě ten případ, kdy selhal planner postavený na statistikách, protože statistiky neměl k dispozici. Což je spíše ta výjimka, která potvrzuje pravidlo.

Ta podmínka tam být musí, protože pouze jedna není (jakákoliv) není v rámci této úlohy jednoznačná. Zaměstnanci, které chci vybrat, mají nejvyšší mzdu v rámci oddělení - tudíž jsou potřeba dvě kritéria (mzda, a oddělení). Pokud by tam bylo pouze oddělení, tak mi to vypíše všechny zaměstnance, pokud dám pouze mzdu, tak to zhavaruje v případě, že sekretářka v administrativě má 10K (nad ní je ovšem ředitel s 20K), a hlavní inženýr z vývoje má 10K.

Tohle je v každé databázi jiné. V Sybase based databází (včetně MySQL) se používá dočasná tabulka. Firebird má k tomu příkaz SUSPEND, která do výstupu přidá kopii OUT proměnných. V PostgreSQL jsou SRF funkce a RETURN NEXT. v PostgreSQL taková užitečná funkce generující tabulku o jednom sloupci a n řádků obsahující vzestupou posloupnost, která se jmenuje generate_series. Její zdroják by byl (kdyby byl v plpgsql, je ale v C) následující:

CREATE OR REPLACE FUNCTION generate_series(start integer, konec integer)
RETURNS SETOF integer AS $$
BEGIN
  FOR i IN start .. konec LOOP
    RETURN NEXT i;
  END;
  RETURN;
END;
$$ LANGUAGE plpgsql; 

Proto je duležité nepsat jak dobytek :)). A držet se ověřeného: Císařovo císaři, papeži papežovo..

Totiz to Vase zadani neni jednoznacne. Budto chcete vsechny zamestnance nebo chcete ty, jejichz pracovni neschopnost presahla 10 hodin. Pouze v pripade, ze by vsichni zamestnanci byli nemocni dele nez 10 hodin, tak lze na ni odpovedet. Jinak ty Vase priklady jsou presne tou ukazkou proc striktne pouzivat JOIN ON, ale korektne zapsany (nikoliv s Vasi zamernou chybou). Pak muzete bezpecne menit INNER JOIN na OUTER JOIN a nedockate se prekvapeni. Na neco podobneho jsem narazil v manualu k 7 MSSQL, kde ukazovali vyhody JOINU vuci klasickemu spojeni vyctem v FROM.

Pokud bych to mirne preformuloval. Chci zaznamy vsech zamestnancu, a jejich pracovni neschopnosti, s tim, ze u zamestnancu, kteri maji p.n. mene nez 10h zobraz nulu. Je to ono?

SELECT jmeno, prijmeni, CASE 
                            WHEN pocet IS NULL THEN 0
                            WHEN pocet <= 10 THEN 0
                            ELSE pocet END
   FROM Zamestnanci z
        LEFT JOIN
        PracovniNeschopnosti p
        ON z.id = p.zam_id;

Pokial mal clanok sluzit ku objasneniu rozdielov medzi LEFT / RIGHT / INNER / OUTER join, tak rozhodne chybaju vysledky uvedenych prikladov. Autor zrejme predpokladal citatelovu zrucnost a predstavivost (kde budu NULLy, kedy sa ktory riadok zaradi do vysledku..). Avsak takyto citatel zjavne davno vie, ako dane JOINy funguju.
Chcem tym povedat strucne - pre zaciatocnika prilis slabo vysvetlene, pre pokrocileho prilis malo informacii.