Názory k článku Markus Winand: SQL Performance Explained

"Určitě je ale vhodné mít základy pro každou používanou technologii a vědět něco i o věcech, které se zrovna ve firmě nepoužívají."

To je v hrubém rozporu s požadavky firem, jak lze vidět z komentářů, které se ady občas vyskytnou.
Jakékoliv hlubší znalosti nejsou vítány a jsou zbytečné. Jednak mohou být dotyční lidé s těmito znalostmi chytřejší, než průměrný manažer, což je nežádoucí, a nebo mají přemíru samostatného myšlení, což je taky nežádoucí. Ideální je člověk co umí výborně používat nějakou technologii, moc nekecá a dělá co se mu řekne.

V tzv. "velkych" firmach jde i o nahraditelnost cloveka. Proto vesmes manageri pristupuji k lidek jako ke kusu dobytka. K cemu je ti nekdo chytrej, kdyz ho pak sejme nekde ponorka na prechodu a ty nemas nikoho, kdo by ho nahradil a projekt timeline jde do ... ? Proto je "lepsi" resit veci hrubou silou, ve smyslu poctu. A proto bych nikdy v takove "firmne" delat nemohl (o: Dokonce jsem zazil, ze firma preferovala kod, co byl napsanej vylozene spatne - ale protoze pouzival jen std. navrhove vzory, mohlo do nej koukat kazde pako. Extrem je pak to, kdyz se pouzivaji JEN navrhove vzory. At zije management :)

R.

Takže celý článek je vlastně jenom reklama. Žádný přínos tu není kromě potencionální knížky o databázích kterou si dokáže každý vyhledat sám. Odkdy je root reklamním serverem?

http://cs.wikipedia.org/wiki/Recenze

Nemyslím si, že jde o reklamu.

Četl jsem zde na Rootu s chutí několik autorových článků a věřím tomu, že problematice rozumí.
Naopak nevěřím tomu, že by měl zájem dělat reklamu zde nějaké publikaci. Proto děkuji za krátkou recenzi publikace a půjdu se zeptat zaměstnavatele, jestli bychom ji nemohli koupit do knihovny ;-)

Dakujem za recenziu, urcite si ju kupim.

Mne osobne to prislo fajn, protoze po techto vecech nekoukam. Jsem odkazan na to, ze kdyz nekdo ze sveho oboru narazi na neco zajimaveho, upozorni na to.

Spise by mne zajimalo, jesli ta uroven konci na podobnem "prikladu" (coz je opravdu "o nicem" a vychazi to jen z logiky veci) nebo jsou tam reseny veci, ktery uz nejsou vubec zrejmy (ruzny joiny, poradi vnorenych selektu, ....). A jestli to ma vlastne zas takovej prinos, vzhledem k tomu, ze si to planer stejne prekope "jak se mu libi".

Jestli bych se mohl Pavla na neco zeptat, jak by otazka znela: je knizka prinosem oproti pouziti "query plan" na postgresu (jinou DB osobne nepouzivam) ? Jesli ano o kolik :) Pac potom by za to asi stala. Papir je papir (:

Dekujemes

R.

Diky :)

R.

Několik let jsem se víceméně živil optimalizací dotazů a reportů pro databázi Oracle. Prakticky cokoliv se dalo s pomocí indexů a vhodně zapsaných podmínek zrychlit. Obvykle se dařilo report, co běžel hodinu, zkrátit na několik desítek sekund. Ne proto, že bychom byli nějací úžasní mistři světa, ale proto, že autor původního kódu byl trouba.

Tou nejtriviálnější a bohužel i nejčastější chybou jsou neúplné dotazy.

Příklad:
Máme tabulku T1, klíč je A.
Máme tabulku T2, klíč je složený A a B.
Bohužel se pak běžně potkáte s dotazem:

SELECT ..
FROM T1, T2
WHERE T1.A = T2.A
AND T1.A = 'a'
AND T2.B = 'b'

Lidem, co tohle dokáží napsat, nepomůže ani svěcená voda. Přepsání do syntaxe INNER JOIN to může zatemnit, ale na výsledku nic nezmění. Do tabulky T2 se to prostě celým indexem nekoukne ani za zlaté prase. A přitom jsou hned tři způsoby jak to zlepšit. Který je nejvhodnější už závisí na konkrétních datech a je to potřeba zkusit. Konkrétně:
1. Změnit " AND T1.A = 'a' " na " AND T2.A = 'a' "
2. Přidat podmínku " AND T2.A = 'a' "
3. Tabulku T1 do joinu vůbec nedat a data z ní do SELECT vytaháme pomocí vnořeného selectu. Tedy něco jako:

SELECT T2.*, (select x from T1 where t1.A = t2.A)
FROM T2
WHERE T2.A = 'a'
AND T2.B = 'b'

Jakkoliv tato třetí metoda vypadá prasácky, tak v případech, kdy potřebuji jen jeden údaj a tabulka T2 má o několik řádů více záznamů než tabulka T1, to dává zdaleka nejlepší výsledky. Pokud máte v tabulce T2 data a tabulka T1 je jen nějaký slovník přiřazující popis ke kódům, je toto kupodivu nejrychlejší řešení.

Generalizaci jsi to zabil, kdyz uz hlasas, mel by sis vybrat co a nepopirat same sebe. Neni pravda, ze by subquery byly vzdy rychlejsi, zalezi na optimizeru jak bude vysledny dotaz v pripade subquery interpretovat, muze se totiz lehce stat, ze to prevede na inner join...
Tudiz bych se s tim "tomu nepomuze ani svecena voda" mirnil;-)

Vase vypraveni je vyborna ukazka, jak nesmyslna vlastne ta cela SQL technologie je. Jiste, rozsirilo se to a neni pred tim uniku, ale kdyz uz se mame zamyslet, tak proc ne hned nad tim, kolik hruzy uz ta cela sql na lidstvo uvalila :-)

Jiste je krasne, ze se zivite tim, ze ty nesmysly, ktere pouzivanim sql vznikaji castecne korigujete. Ale predstava autora knihy a i autora recenze, ze se ja, aplikacni vyvojar, budu pri vsi me praci jeste zabyvat optimalizaci dotazuu je opravdu smesna. Kdo chce koncovemu zakaznikovi predat kvalitni dilo, ten ma jiz plne bryle te zakaznicke problematiky a jednoduse potrebuje nastroj (black-box), ktery za nej 'uschovu' dat prevezme.

V praxi to nakonec vypada tak, ze na puli cesty zustanou smysluplne pozadavky zakaznika a misto toho se cele tymy 'databazovych' odborniku snazi privest reseni postavene na sql-technologii k jakz takz rozumnemu provozu.

> Do tabulky T2 se to prostě celým indexem nekoukne ani za zlaté prase.

Je fajn, ze sa SQL tlaci medzi vysokourovnove deklarativne jazyky, ostava uz len pisat sql parsery, tak aby platilo to, co sa v matematike uci na zakladnej skole niekde v druhej triede. IF a = b AND b = c THEN a = c. Bohuzial sa tu na roote najdu experti, co si na takto odflaknutych databazovych implementaciach postavili business model. Obdobne ako antivirus industry profituje z neochoty MS fixovat bugy.

Hlupáku. Kdybys byl co k čemu, tak jméno autora článku je dost známé. Děkujme za to, že nám hází perly. Snad ho podobně tupí jedinci, jako ty, neodradí od této činností. Díky.

Chvili jsem hledal, ale v zadnem obchode v CR jsem ji nenasel.

Vi nekdo o nejakem ceskem obchode (nebo zahranicnim, kde jim staci platba pres paypal a nevyzaduji kreditni kartu), kde se da tato kniha koupit?

Koupil jsem ji přímo na autorově webu platba přes Pay-pal, do týdne doma. :)
http://sql-performance-explained.com/

na bookdepository ju nemozem najst :(

dik!

Koupil jsem papirovou i PDF verzi, a nelituji toho, protoze PDF je formatovano dostatecne "rozmerne", ze se da pohodlne cist i na kindlu bez PDF reformatovani (nebo jak se to jmenuje).
No a hlavne uz si muzu cist nez mi dojde papirova verze..

No mne naskakuje husia koža aj keď vidím alternatívu b (ktorá je uvádzaná ako dobrá). Je možno lepšia ako a z performance hľadiska, ale pre mňa dobrá je maximálne ako workaround.
Predsa SQL interpret musí vedieť implicitne skonvertovať string vo formáte 'YYYY-MM-DD' (poprípade iný vopred daný formát) na dátum. Konverzie dátumov na string a naopak sa má predsa robiť len na UI vrstve.
Milujem keď čítam zdrojový kód a vidím že developeri hore dole na applikačnej a SQL vrstve konvertujú dátumy na string a naopak.

Mno ... nevim jak ktera databaze, ale minimalne nektery ti v pripade varianty A budou provadet konverzi VSECH zaznamu v tabulce na char, aby je slo porovnat s charem, kdezto v pripade druhym, se konverti jednou pred zahajenim dotazu, kterej je o porovnani s konstantou ... coz muze byt i radove rychlejsi.

Jestli pak budes provadet explicitni nebo implicitni konverzi ... to uz je jen otazka "sychr je sychr", protoze formaty datumu ... to je v databazich kapitola sama pro sebe (stejne jako desetinna tecka vs carka ...).

Zcela zjevne si nikdy nic zasadniho neresil, protoze jinak by ses nad takovou drobnosti vubec nepodivoval. Ja tu mam trebas M$ SQL a to, v jakym formatu datum zkousne zalezi i na fazi Mesice ... (ja mam EN widle, kolega CZ ... a na problem je zadelano, protoze kdyz mu ja poslu query s implicitni konverzi, on ho proste nespusti a musi si ho predelat).

Len tak naokraj som chcel, že v MSSQL by vás ani CONVERT(DATETIME, 'YYYY-MM-DD') vo všetkých jazykoch nezachránil. CONVERT(DATETIME, 'YYYYMMDD') už áno. Je to relatívne bežný omyl.
Chápem že situácia je taká aká je a kvôli spätnej kompatibilite sa to tak ľahko nezmení. Len sa mi zdá trochu choré že server musí ešte riešiť aj konverziu dátumov podľa nastaveného jazyka a nie proste striktne vyžaduje len jediný správny formát. Zobrazenie a čítanie dátumov v používateľom požadovanom formáte by podľa mojej skromnej mienky malo byť záležitosťou UI.

To souhlas, ale proste je to tak jak to je, ze primo SQLko umi vracet datumy v ruznych formatech na prani ... a uplne stejne se chovaji desetinna cisla, kde z toho podle nastaveni vylezou tecky nebo carky. A to znam i aplikaci, kde se pri komunikaci pres XML vyplnuje zhruba nasledovne:


[OBJEDNAVKA]
[POLOZKA zbozi="sud" baleni="3,5"]4­.7[/POLOZKA]
[/OBJEDNAVKA]


Proste nejakou hlavu vymazanou by bylo treba strcit do 1/2coulovy vodovodni trubky ... zjevne by se tam vpohode vesla.

Ja tu neriešim variantu A, mne sa len nepáči varianta B a ani to nie s ohľadom na performance, ale kvalitu kódu. Ja som proste zástanca jednoduchosti a nepáči sa mi keď niekto rieši niečo na vrstvách na ktoré to nepatrí.

No trochu sa ma dotklo keď si ma obvinil na základe tvojich dojmov že som nič poriadne neriešil :). Ja som veru nikoho konkrétneho neurážal. Ale keď vidím mnohých diskutujúch ktorým etika na fórach nič nehovorí, tak sa nad tým len pousmejem.

Keby si mi radšej napísal ako v tvojich zásadných riešeniach postavených na M$SQL postupuješ keď nevieš aký je nastavený jazyk a aká je fáza mesiaca. Pretože ja som na podobný problém ešte nenarazil. Asi som príliš zásadový dátum vždy píšem ako YYYYMMDD alebo YYYY-MM-DDTHH:MM:SS (poprípade YYYY-MM-DD ale to len keď sa hrám v konzole a chcem aby to pekne vyzeralo, každopádne ako generovaný string z DB adaptéra by som to pre MSSQL nepoužil). Počul si už o ISO 8601 o ktorom už počuli aj súdruhovia v M$?

Pouzivat muzes format jaky chces, potiz je v tom, ze ty jednoduse predem nevis, jak se rozhodne to M$ SQL ze ma/nema nastavenej jazyk/konverze. Pokud mas aplikaci + server naprosto ve svy moci, tak se sice da spolejhat na to, ze se to bude chovat porad stejne (dokud to neopatchujes), ale k databazi/serveru se vetsinou taky pripojujou nejaci klienti ... a u tech proste to, jak maji nastavenej jazyk neovlivnis. Navic prave v pripade widli je velmi zasadni rozdil, jestli jde o widle anglicke s ceskou lokalizaci nebo widle ceske ... a to na vsech urovnich (jak srv tak klient).

A potom konverzi zajistuju tam, kde uz to mam ve sve moci - tedy klido na urovni SQL. Totiz ona bezpecnost/kon­zistence dat/... je o asi tak rad dulezitejsi, nez nejaka milisekunda.

BTW: Spousta "webaru" pouzivajicich MySQL vubec netusi, jak (spravne) tu databazi pripojit, a pak se divej, ze maj potize s diakritikou, s hledanim ... a datumy, protoze vubec netusej, ze jsou 3 mista, kde to musi nastavit - a jedno z nich je trebas vlastni konexe do databaze, kde se prave spolejhaj na nejakou implicitni hodnotu ... o ktere vubec nevi ze existuje.

(pro zajimavost, v pripade webu je treba znat nataveni databaze, nastaveni konexe a pak jeste poslat spravne hlavicky - jinak to nebude fungovat)

A mohl byste, misto zavadeni debaty jinam (ruzne formaty zapisu data), treba napsat variantu C, ktera by podle Vas byla spravne?

Pokud vim, jeho predstava je, ze to ma vypadat takhle:


SELECT
FROM sales
WHERE sale_date = '19700101';


Coz bude sranda, az tam napisu '19700511' a pak se bude resit, jestli je to 11.5. nebo 5.11. ... nebot oboji je jiste mozne (a i ten vice imbecilni zapis - tedy YYYYDDMM sem uz videl - pouzivaj ho britove, podobne jako palce a stopy ...).

Pokud tam je ta konverze, tak je zcela jasne, co tim pisatel minil a tudiz netreba resit, jak je zrovna nastaveny prostredi.

No myslel som si že to priamo vyplýva z toho čo som napísal, ale to môže povedať o sebe každý. Takže sa ospravedlňujem a skúsim ešte raz:
Neodsudzujem autora že robí CONVERT, ja to ale nepovažujem za ideálne riešenie, ale ako nutné zlo (workaround), a úplne chápem že na niektorých serveroch sa to proste robiť musí. Kebyže Convert nebol potrebný, nikdy by developer nebol omylom napísal niečo ako Variant A (iba ak naschvál).

V ideálnom svete by každý SQL server ktorý vie že sale_date je typu date/datetime pochopil

SELECT FROM sales
WHERE sale_date = 19700101

ale nie som ortodoxný. Celkom by mi stačilo aby si každý výrobca SQL servera zvolil svoj formát, ktorý vie za každých okolností implicitne rozparsovať
(napr. '19700101', '1970-01-01')

Implicitní konverzi je obecně lepší se vyhnout. Navíc třeba konkrétne u Oracle nevíte co vlastně bude konvertovat.

Dotaz

select * from tabulka where sloupcec_typu_strin­g=1;

proběhne tak, že se pokusí zkonverovat hodnoty soupečku na číslo (a přitom samozřejmě většinou spadne)

Anebo tenhle spek:
select * from t where a between :b and :c

kde a je DATE, :B, :C jsou stringy anebo cisla. Jak se to nakonec porovna?

Uvedeny priklad a konverzia to_date('1970-01-01', 'YYYY-MM-DD') je uplne spravna a presne takto sa to ma robit. Pretoze neexistuje, aby sa to ponechalo na implicitnu konverziu. Naopak, komukolvek, kto ponechava konverziu na DATE na system a robi implicitnu konverziu, by som lamal ruky. Jedine co by som vylepsil je na to_date('19700101', 'YYYYMMDD') .

Ono by možná pro zrychlení či odstranění některých problémů úplně stačilo použít něco jiného než relační databázi (dále jen RD).
Je ironií, že autor píše o fixaci na jednu technologii, ale přitom se sám fixuje na RD se SQL. RD se používají na každou pičovinu, přičemž většina reálných dat nemá vůbec povahu relací, takže nutně přichází mapování (obvykle na objektový model), ale to něco stojí. A zde pochopitelně přichází kámen úrazu a všichni se velice diví, proč je to pomalé a v potu tváře hledají nejoptimalizo­vanější maxiselecty, které budou danému db serveru dost dobré.

Nemám nic proti používání věcí, které fungují, ale relační databáze přece nejsou jedinou věcí, která funguje, a pro seznam hovorů a SMS v telefonu jsou předimenzovaným řešením. Problém je v onom nepěkně pojmenovaném procesu „ohýbání“ - ono když se něco moc ohýbá, většinou to pak stojí za hovno (osobní zkušenosti).

ty si zřejmě představuješ že v tom telefonu musí bejt něco jako postgres, ale tak to není; i dvě blbý .csv + příkaz join de označit jako relační databázi

ORM = JPA? To je opravdu JPQL o tolik jednodussi nez SQL?

Ja myslim ze nesmysl je používat něco takového jako je ORM. K cemu? zaneseni slozitosti? neefektivita tohoto kodu....

No, tak důvodem ke vzniku OOP bylo právě připodobnění k realitě, takže je na tom v modelování reality velice dobře, ale to je můj osobní názor. Ale jestliže máte v paměti objektový model (tedy graf) a chcete ho uložit, je asi hovadinou zkoušet ho rozstříhávat na (principiálně nekompatibilní) relace a potom ho zase pracně z relací skládat (bez ohledu na použitelnost dnešních objektových DB), když je možné jej uložit zase jako graf. To se snad shodneme. A kdo někdy v aplikaci ORM používal, ví, co je to za peklo a balast navíc představující nemalou část aplikace.

RDB pracuje rychle s relacemi, které jsou uložené v jedné či pár tabulkách, v okamžiku, kdy je relace sestavena z mnoha tabulek (typická situace u členitých doménových modelů), jde výkon vlivem spojování tabulek do řiti.
RDB jsou rozšířené, protože začaly nejméně o 10 let dříve než ODB a protože IT má velkou setrvačnost, takže jejich vytlačení do jejich oblasti užití bude nějakou dobu trvat.
Zastupitelné jsou (vizte dnešní stav), ale dře to.