SQL dotaz bez opakování výsledků

[karel]

A mozna proto jaky je bordel s vyhodnocenim sql v ruznych databazich ruzne zacina vice a vice pouzivat nosql spojeni,
jinak mssql stoji za, ale co se musi nechat posledni verze maj dobre udelany execute planovac ikdyz je to asi jen kvuli tomu jak nam hloupnou programatori, ale poradi si opravdu s prasarnama, a jak to udelaly ? logovaly prasarny a pro ty nejcastejsi pridali definice planu. Takze za planovacem nehledejte nic svetaborneho, proste napsanim sql dotazu ikdyz se to nektreym lidem neliby ovlivnujete jeho vykonani a navic je to per databaze jine.

[Reklama]

[Někdo]

Ja som si vzdy myslel a aj s tym zijem, ze Databazovey engine moze spravit optimalizaciu, ale aj ja mu viem dat vediet ze nechcem to optimalizovat alebo mu podstrcit to akym smerom sa ma jeho optimalizacia uberat.
Takze si nemyslim "...že progamátor nemá přímou kontrolu nad tím jak se budou složitější dotazy..."

Různí dodavatelé různých databází mají různé způsoby jak do klasického deklarativního SQL propašovat imperativní prvky (s tím žádný standard SQL nepočítá), ale bohužel ne vždy to funguje. Proto si myslím že programátor který databázi posílá SQL dotazy tu přímou kontrolu nemá. Názorný příklad je třeba posun od rule based optimizeru který fungoval u Oracle naposledy v databázi verze 9.2 k aktuálně používanému cost based optimizeru - tam když vám databáze nenabídne execution plan který by se vám líbil tak máte smůlu, prostě to ta databáze tak jak byste chtěli dělat nebude (hinty jsou často ignorované, na rozdíl od rule based optimizeru). Jde o oddělení toho co se má dodat za výstup (určuje programátor tím jaký zadá SQL dotaz) od toho jak se k tomu výstupu dostat (určuje databáze, pouze částečně to může ovlivnit její administrátor).

[Filip Jirsák]

Ja som si vzdy myslel a aj s tym zijem, ze Databazovey engine moze spravit optimalizaciu, ale aj ja mu viem dat vediet ze nechcem to optimalizovat alebo mu podstrcit to akym smerom sa ma jeho optimalizacia uberat.
Takze si nemyslim "...že progamátor nemá přímou kontrolu nad tím jak se budou složitější dotazy..."

Exekuční plán neřeší jenom optimalizace, ale především to, jak se vůbec dotaz bude provádět. Vy databázi říkáte jenom co chcete, a databáze z toho vyrobí jak to dostat – optimalizace je až následný krok. Nad tím převodem z co na jak programátor opravdu přímou kontrolu nemá. Samozřejmě ale může to samé co vyjádřit různými způsoby (přičemž ne vždy databáze může poznat že jsou ty varianty ekvivalentní – protože programátor může zahrnout i nějaký předpoklad, který v databázovém schématu není vyjádřen), a také může dát databázi různé nápovědy k tomu, jak exekuční plán sestavit.

Pokoušet se ale optimalizovat dotaz zrovna v tomhle případě je nesmyslné, protože pokud už by bylo potřeba tuto věc optimalizovat, je jediné rozumné řešení normalizovat databázi. A pak nebude co na dotazu optimalizovat, protože to bude výpis všech hodnot v jednom číselníku.

[j]

Maly (zcela realny) priklad. M$SQL (jedno jake verze). cosi is null vs isnull(cosi,0) = 0. Druha varianta je asi tak 100x rychlejsi. Divne co? Dtto prozmenu pouziti datediff() je asi tak 1000x pomalejsi, nez proste odecitani/scitani. Nekdy o tom, jestli dotaz vubec dobehne, rozhoduje i poradi.

Prosím nezobecňuje chování všech SQL databází podle jedné implementace, navíc zrovna takové hodně špatné. Microsoft SQL je jen hračka dobrá nanejvýš pro zpracování malých dat, i když uznávám že to verzi od verze celkem dost zlepšují - ke špičkovým databázím mají ale ještě daleko.

Uvadim zcela konkretni priklady na zcela konkretnim typu databaze, zobecnuje tu nekdo jiny bych rek. A chovani databaze se zapisem dotazu naopak ovlivnuje velmi dobre, a byva dobrym zvykem tech, kteri vedi co cini, to i delat. On totiz ten parser psal taky clovek, takze cim primocarejsi a pochopitelnejsi je zapis, tim vetsi sance je, ze to DB pochopi presne tak, jak to pisatel mini. Zapisem se da kuprikladu velmi dobre ovlivnit, jake idexy databaze pouzije (a v nekterych implementacich to lze pak i vynutit).

Dufam ze nahradenie "cosi is null" vyrazom "isnull(cosi,0) = 0" nepatri medzi tvoje standartne programove riesenia....
Ak hej... lopata ti pristane viac....

No jiste, kvuli tupcum jako ses ty budu pouzivat 100x pomalesi dotaz ... ja totiz (nejspis narozdil od tebe) nejsem placenej za to, jak query vypada, ale za to, jak funguje. Uz vidim, jak zakaznikovi vysvetlujes, ze to zauctovani faktury trva sice 10 minut, a on kvuli tomu tech 10 minut nemuze delat nic jinyho, ale ten dotaz prece vypada tak krasne.

Mimochodem, muj rekord je pokud si pamatuju dobre 30minut vs 30s. (samo, nejen uprava dotazu, on si nejen tvurce rejstriku aut mysli, ze index je sprosty slovo).

[Dzavy]

Maly (zcela realny) priklad. M$SQL (jedno jake verze). cosi is null vs isnull(cosi,0) = 0. Druha varianta je asi tak 100x rychlejsi. Divne co? Dtto prozmenu pouziti datediff() je asi tak 1000x pomalejsi, nez proste odecitani/scitani. Nekdy o tom, jestli dotaz vubec dobehne, rozhoduje i poradi.

To je snad logický ne? Buď máš index na cosi nebo na isnull(cosi, 0). Datediff to samý. A některý DB indexy nad funkčníma výrazama ani neumí, tak tam to ani sebelepší optimalizátor nepořeší...

[Reklama]

[NooN]

Dufam ze nahradenie "cosi is null" vyrazom "isnull(cosi,0) = 0" nepatri medzi tvoje standartne programove riesenia....
Ak hej... lopata ti pristane viac....

No jiste, kvuli tupcum jako ses ty budu pouzivat 100x pomalesi dotaz ... ja totiz (nejspis narozdil od tebe) nejsem placenej za to, jak query vypada, ale za to, jak funguje. Uz vidim, jak zakaznikovi vysvetlujes, ze to zauctovani faktury trva sice 10 minut, a on kvuli tomu tech 10 minut nemuze delat nic jinyho, ale ten dotaz prece vypada tak krasne.

Mimochodem, muj rekord je pokud si pamatuju dobre 30minut vs 30s. (samo, nejen uprava dotazu, on si nejen tvurce rejstriku aut mysli, ze index je sprosty slovo).

Ked dochadzaju argumenty, zaciname s ponizovanim....

Vyrazy "cosi is null" a "isnull(cosi,0) = 0" davaju rozne vysledky, ale ked myslis.... pokracuj dalej vo svojej odbornej praci a zelam vela stastia pri hladani chyb.

[j]

Vyrazy "cosi is null" a "isnull(cosi,0) = 0" davaju rozne vysledky, ale ked myslis.... pokracuj dalej vo svojej odbornej praci a zelam vela stastia pri hladani chyb.

A odkedy kefalin ?   cosi is nul je jinak receno (nebot provnavat null jaksi moc nelze) cosi = null. isnull(cosi,0) nedela nic jinyho, nez ze v pripade ze cosi = null vraci (jak prekvapive) 0. A jiste, pocita se s tim, co muze pripadne nemuze byt obsahem cosi. Jenze pro dany ucel je mi to zcela uzadeke. Paac anzto aprotoze, pokud by tam nahodou byla nula, tak je mi to zcela jedno. A az tam nulu nebudu chtit, napisu si tam trebas 'NooN'. Furt to bude 100x rychlejsi. Jenze nekteri idioti pochopitelne nedokazou pochopit, ze priklad je priklad, zeano.

[Kolemjdoucí]

Ja som si vzdy myslel a aj s tym zijem, ze Databazovey engine moze spravit optimalizaciu, ale aj ja mu viem dat vediet ze nechcem to optimalizovat alebo mu podstrcit to akym smerom sa ma jeho optimalizacia uberat.

Ne, optimalizace se dělá vždy. Směr optimalizace se v jisté malé míře ovlivňovat dá.

A mozna proto jaky je bordel s vyhodnocenim sql v ruznych databazich ruzne zacina vice a vice pouzivat nosql spojeni,

Bordel není prakticky žádný, kromě pár známých specialit. NoSQL není náhrada relační databáze, je to jiná záležitost pro jiné účely.

[NooN]

Vyrazy "cosi is null" a "isnull(cosi,0) = 0" davaju rozne vysledky, ale ked myslis.... pokracuj dalej vo svojej odbornej praci a zelam vela stastia pri hladani chyb.

A odkedy kefalin ?   cosi is nul je jinak receno (nebot provnavat null jaksi moc nelze) cosi = null. isnull(cosi,0) nedela nic jinyho, nez ze v pripade ze cosi = null vraci (jak prekvapive) 0. A jiste, pocita se s tim, co muze pripadne nemuze byt obsahem cosi. Jenze pro dany ucel je mi to zcela uzadeke. Paac anzto aprotoze, pokud by tam nahodou byla nula, tak je mi to zcela jedno. A az tam nulu nebudu chtit, napisu si tam trebas 'NooN'. Furt to bude 100x rychlejsi. Jenze nekteri idioti pochopitelne nedokazou pochopit, ze priklad je priklad, zeano.

Z teba by bol dobry predajca, vzdy si vsetko prekrutis ako ti to vyhovuje. Ale budis. Ty si pan.

[Ivan]

Různí dodavatelé různých databází mají různé způsoby jak do klasického deklarativního SQL propašovat imperativní prvky (s tím žádný standard SQL nepočítá), ale bohužel ne vždy to funguje. Proto si myslím že programátor který databázi posílá SQL dotazy tu přímou kontrolu nemá. Názorný příklad je třeba posun od rule based optimizeru který fungoval u Oracle naposledy v databázi verze 9.2 k aktuálně používanému cost based optimizeru - tam když vám databáze nenabídne execution plan který by se vám líbil tak máte smůlu, prostě to ta databáze tak jak byste chtěli dělat nebude (hinty jsou často ignorované, na rozdíl od rule based optimizeru).

Kdyz se CBO objevil tak to byla prvni vec kterou DBAcka vypinali. Vsichni z toho byli nestastni. Dneska cca po 17ti letech se situace obratila. Je to podobne jako u nekonecne debaty C++ vs. ASM. Vsichni vedi ze kod napsane v assembleru muze byt rychlejsi nez kod v C++. Dneska uz ale potkate malo lidi, kteri by skutecne umeli kompilator porazit. Podobme je to s CBO u Oracle, porad jeste se pouzivaji hinty (treba u ETL) ale v drtive vetsine pripadu proste optimizer vymysli lepsi plan nez programator.  Dneska uz opravdu nema cenu s optimizerem prat. Jinak pokud opravdu potrebujete vedet jak optimizer pracuje a v jakem poradi prochazi jednotlive permutace tabulek, tak staci spustit "alter system trace 10053" a database vam vyplivne i trace z optimalizace.

[dfadga]

A mozna proto jaky je bordel s vyhodnocenim sql v ruznych databazich ruzne zacina vice a vice pouzivat nosql spojeni,

http://www.nosql-vs-sql.com/

[hmmm]

Hele, nehodlam se do tebe poustet. Asi si tady vsichni uvedomuji rozdil mezi "... is null" a "isnull(..., 0) = 0" a ty snad vis, co muze nebo nemuze nastat.

Spis me zajima, jestli jsi zkousel hloubat nad tim, proc to zpusobovalo takovy rozdil v rychlosti? Nekdo tady zminil, ze to beztak muselo byt indexama. Tak jak to bylo? Byly tam nejake indexy? Nebo to mohlo byt necim jinym?

[NooN]

Zacal asi opravovat svoje projekty

[j]

Hele, nehodlam se do tebe poustet. Asi si tady vsichni uvedomuji rozdil mezi "... is null" a "isnull(..., 0) = 0" a ty snad vis, co muze nebo nemuze nastat.

Spis me zajima, jestli jsi zkousel hloubat nad tim, proc to zpusobovalo takovy rozdil v rychlosti? Nekdo tady zminil, ze to beztak muselo byt indexama. Tak jak to bylo? Byly tam nejake indexy? Nebo to mohlo byt necim jinym?

To nema kupodivu nic spolecnyho s indexama, to je proste o tom, ze neni porovnani jako porovnani, a neni soucet jako soucet.
Viz stejnej pripad je v M$sql datediff(). Je o nekolik radu pomalejsi, nez kdyz na datum pouzijes proste odecitani/scitani cisel. Jinak receno, i pomerne trivialni query, ve kterym chces zaznamy rekneme mladsi dvou dnu, a pouzijes tam tu fci, muze trvat klidne minutu, pricemz, kdyz od data proste odectes 2 a porovnas s aktualnim (nebo od sebe odectes ty datumy), dostanes se klidne pod vterinu. Je to neuveritelny, ale je to tak. Vliv se pochopitelne nasobi poctem porovnavanych zaznamu.

Samo, pokud chces necely dny, tak je to na desetinky a nikoli "uplne presne". Ale komu sejde na nejakych milisekundach...

[NooN]

Proste uplne normalne veci, za ktore moze optimalizacia zo strany seerveru, kde funkciu napr. diff musi aplikovat vzdy, kdezdto zakladne aritmeticke operacie nad "statickou" premmenou (aktualiny datum) si vie zoptimalizovat a pouzit index.