Fórum Root.cz
Hlavní témata => Server => Téma založeno: Picmaus 19. 11. 2014, 13:42:04
-
Zdravim komunitu,
muze mi tu nekdo sbehly v (My/Lite)SQL poradit s dotazem?
Problem prevedu do jednoduche podoby.
Mam tabulku INVENTAR ktera obsahuje krom dalsich i polozky 'budova' VARCHAR(1) a 'podlazi' INT.
Tabulka obsahuje mnoho zaznamu kde jsou kombinace budova a podlazi casto stejne pro ruzny inventar.
Budova nabyva oznaceni od A do Z a podlazi od 0 do neznama.
Napr.
name='Zidle' type='Chair' budova='B' podlazi=2
name='Stul' type='Table' budova='B' podlazi=1
name='Kreslo' type='Chair' budova='B' podlazi=2
Potrebuji udelat seznam budov a podlazi pro inspekci inventare kde se nejaky vyskytuje ale bez opakovani.
Tj. aby v nem budova='B' podlazi=2 byla jen jednou
Dekuji
-
Podotykam ze zaklady SQL znam, bude tam nejspis neco jako
SELECT budova, podlazi FROM INVENTAR WHERE <combination of buova.podlazi is not in select result yet>
-
Potrebuji udelat seznam budov a podlazi pro inspekci inventare kde se nejaky vyskytuje ale bez opakovani.
Tj. aby v nem budova='B' podlazi=2 byla jen jednou
klucove slovo pre google sa vola "DISTINCT"
-
SELECT DISTINCT budova, podlazi FROM …
DISTINCT (http://dev.mysql.com/doc/refman/5.6/en/select.html#idm140658218334816)
Jsou to základy SQL…
-
nerikej opravdu znas ?
-
Možností, jak toho dosáhnout, je několik. Třebas zmíněný DISTINCT nebo vhodně zvolené GROUP BY (to vám navíc umožní přidat COUNT). Ale nikdy jako WHERE podmínka. Základy SQL vám opravdu chybí. A tím teď nemám na mysli syntaxi, ale vůbec chápání, co SELECT je. To referenční příručka nedožene, na to je potřeba učitel nebo učebnice.
-
Dekuji vsem za odpovedi, s SQL valim jen velmi okrajove a DISTINCT jsem i tak nikdy nepouzil - normalne bych pro notoricky opakovane hodnoty 'budova' a 'podlazi' zvolil spesl tabulku s id (1:n vazba) pro mensi objem databaze. Coz v realnem resenem problemu mozne neni.
To Karel
WHERE bych tam stejne nedal (chybi specificka podminka podle ktere filtrovat, ze) to jsem nechal v pseudo dtazu schvalne aby kazdy pochopil o co mi jde.
-
to karel (ten prvni)
S programovanim jako profesi jsem sekl pred ctyrmi roky, jak jsem si precetl Vas komentar tak mi to hned pripomelo proc :)
-
Podotykam ze zaklady SQL znam ....
... SQL valim jen velmi okrajove a DISTINCT jsem i tak nikdy nepouzil ...
To ma bejt nejakej druh humoru? :D
-
to karel (ten prvni)
S programovanim jako profesi jsem sekl pred ctyrmi roky, jak jsem si precetl Vas komentar tak mi to hned pripomelo proc :)
ja kdyz si precet dotaz tak to take chapu :)
-
To tommm
Prisaham ze jsem DISTINCT doposud nemel potrebu pouzit a nebo mi uz pamet neslouzi.
To je tezky, jsem nauceny ze duplicity do DB nepatri jeste z dob IT praveku kdy 1MB neco znamenal..
To karel
No vidite ten pokrok, uz mi netykate..
-
Prisaham ze jsem DISTINCT doposud nemel potrebu pouzit a nebo mi uz pamet neslouzi.
Dokonce existovalo i klíčové slovo UNIQUE ...
To je tezky, jsem nauceny ze duplicity do DB nepatri jeste z dob IT praveku kdy 1MB neco znamenal..
Ale ony jsou duplicity a duplicity.
Asi bych se mrkl na to, proč/jak/kdy/za_co/kdy_ne normální formy ...
-
Prisaham ze jsem DISTINCT doposud nemel potrebu pouzit a nebo mi uz pamet neslouzi.
Dokonce existovalo i klíčové slovo UNIQUE ...
Jo tak UNIQUE si pamatuju, to se ale pouzivalo jako atribut pri CREATE TABLE, ze?
Bohuzel nic co by mi pomohlo kdyz uz tabulka existuje (mozna tak pri CREATE TEMPORARY TABLE ?)
To je tezky, jsem nauceny ze duplicity do DB nepatri jeste z dob IT praveku kdy 1MB neco znamenal..
Ale ony jsou duplicity a duplicity.
Asi bych se mrkl na to, proč/jak/kdy/za_co/kdy_ne normální formy ...
Tak tak, v prikladu kde mam budova VARCHAR(1) a podlazi INT (mel by byt shortint/char) by zrovna mely zustat protoze sizeof(VARCHAR(1)) + sizeof (shortint/char) < sizeof (INT) pro id. Neni to tak?
To je ale pouze vhodne zvoleny priklad, realny pripad VARCHAR(28) a VARCHAR(8) je zvlast tabulka jasna volba..
To uz by mi tu ale asi kazdy spilal do amatera a IT neznaboha ikdyz jsem tu tabulku nedelal, ze? ;)
-
To tommm
Prisaham ze jsem DISTINCT doposud nemel potrebu pouzit a nebo mi uz pamet neslouzi.
To je tezky, jsem nauceny ze duplicity do DB nepatri jeste z dob IT praveku kdy 1MB neco znamenal..
Ehm, to se obavam, ze databazi vidis jak jednou za 100let.
Priklad? easy.
Mas rekneme objednavky, a k nim radky se zbozim. Nikde neni receno, ze na jedny objednavce muze byt jedno zbozi jen na jedinym radku. Duvodu jsou tisice, muzes to mit za ruzny ceny, zakaznik si to tak proste objednal, ...
A ted chces trebas zjistit, kteri zakaznici si koupily cojavim ... "uberviagra 2015" protoze je potrebujes sezvat, nebot si zjistil, ze po tom sice neco vstava, ale neco jinyho prozmenu odpada. A chces kazdyho jen jednou.
-
Na tohle GROUP BY/DISTINCT potřeba není.
select * from customers where exists (....)
-
Na tohle GROUP BY/DISTINCT potřeba není.
select * from customers where exists (....)
Jop, jen to bude asi tak to 3 rady pomalejsi ... on je totiz celkem rozdil mit 3 joiny a omezit tim pocet zaznamu na par (desitek) tisic vs poslat do databaze 3 subselecty a probirat kazdym 100M zaznamu.
-
Jsi vedle jak ta jedle, vyjeď si exekuční plán. (Leda že bys používal nějakou hodně historickou DB).
-
Na tohle GROUP BY/DISTINCT potřeba není.
select * from customers where exists (....)
Jop, jen to bude asi tak to 3 rady pomalejsi ... on je totiz celkem rozdil mit 3 joiny a omezit tim pocet zaznamu na par (desitek) tisic vs poslat do databaze 3 subselecty a probirat kazdym 100M zaznamu.
Nejspíš jste si ještě nevšimnul že SQL je deklarativní jazyk, takže to jak zapíšete dotaz nemá přímý vliv na to jak ho databáze provede - volba execution planu v databázi je celkem komplikovaná věc, takže tvrdit že ten korelovaný poddotaz bude databáze provádět jinak (a dokonce náročněji) než ty joiny podle mě je naprosto nepodložená spekulace.
-
Nejspíš jste si ještě nevšimnul že SQL je deklarativní jazyk, takže to jak zapíšete dotaz nemá přímý vliv na to jak ho databáze provede - volba execution planu v databázi je celkem komplikovaná věc, takže tvrdit že ten korelovaný poddotaz bude databáze provádět jinak (a dokonce náročněji) než ty joiny podle mě je naprosto nepodložená spekulace.
;D
ale na to člověk časem příjde jak to v realném životě s tou deklarativností vlatně je
-
Nejspíš jste si ještě nevšimnul že SQL je deklarativní jazyk, takže to jak zapíšete dotaz nemá přímý vliv na to jak ho databáze provede - volba execution planu v databázi je celkem komplikovaná věc, takže tvrdit že ten korelovaný poddotaz bude databáze provádět jinak (a dokonce náročněji) než ty joiny podle mě je naprosto nepodložená spekulace.
Nejspis sis jeste nevsim, jak SQL v realite funguje. Kupodivu i velmi drobna zmena zapisu ma zcela zasadni vliv na vykon a rychlost dotazu. Subselect je pak v 90% zdaleka nejhorsi mozna varianta vubec.
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.
-
Nejspíš jste si ještě nevšimnul že SQL je deklarativní jazyk, takže to jak zapíšete dotaz nemá přímý vliv na to jak ho databáze provede - volba execution planu v databázi je celkem komplikovaná věc, takže tvrdit že ten korelovaný poddotaz bude databáze provádět jinak (a dokonce náročněji) než ty joiny podle mě je naprosto nepodložená spekulace.
Ale stejně tak je naprosto nepodloženou spekulací, že databáze takhle zapsaný dotaz bude provádět stejně rychle. Spoléhat se slepě na volbu execution plánu a ještě jí házet klacky pod nohy není nic, co bych dokázal ocenit. Možná tak medailí za hrdinství. Raději mám defenzivní programování, kdy vhodná optimalizace provedená databází je příjemný benefit, nikoliv životní nutnost.
-
Nejspíš jste si ještě nevšimnul že SQL je deklarativní jazyk, takže to jak zapíšete dotaz nemá přímý vliv na to jak ho databáze provede - volba execution planu v databázi je celkem komplikovaná věc, takže tvrdit že ten korelovaný poddotaz bude databáze provádět jinak (a dokonce náročněji) než ty joiny podle mě je naprosto nepodložená spekulace.
Ale stejně tak je naprosto nepodloženou spekulací, že databáze takhle zapsaný dotaz bude provádět stejně rychle.
Však taky nikdo netvrdí že se takhle zapsaný dotaz bude provádět stejně rychle. Může se provádět pomaleji, stejně rychle i rychleji.
Spoléhat se slepě na volbu execution plánu a ještě jí házet klacky pod nohy není nic, co bych dokázal ocenit. Možná tak medailí za hrdinství. Raději mám defenzivní programování, kdy vhodná optimalizace provedená databází je příjemný benefit, nikoliv životní nutnost.
Tak ještě jednou jinými slovy: SQL je deklarativní jazyk což znamená že progamátor nemá přímou kontrolu nad tím jak se budou složitější dotazy (u kterých je víc než jedna triviální možnost) provádět. To je neoddiskutovatelný fakt. Ano, může se stát že změna zápisu povede k jinému execution planu (rychlejšímu nebo pomalejšímu), ale stejně tak se může stát že execution plan zůstane nezměněný. Volba execution planu v moderních SQL databázích je přímo neovlivnitelná, proto je potřeba se s tím naučit žít a nevytvářet si předsudky v tom smyslu že z toho jak já zapíšu dotaz si mohu bý jistý jak ho databáze provede, protože to u složitějších dotazů rozhodně není pravda - databáze si může volit různé execution plany podle faktorů které vůbec nemám pod kontrolou, jako je například momentální zaplněnost tabulek, konkrétní data v tabulkách (=> selektivita indexů), zatíženost CPU, rychlost disků, zaplněnost RAM a občas mám i pocit že podle postavení hvězd a fáze měsíce.
-
Nejspíš jste si ještě nevšimnul že SQL je deklarativní jazyk, takže to jak zapíšete dotaz nemá přímý vliv na to jak ho databáze provede - volba execution planu v databázi je celkem komplikovaná věc, takže tvrdit že ten korelovaný poddotaz bude databáze provádět jinak (a dokonce náročněji) než ty joiny podle mě je naprosto nepodložená spekulace.
Nejspis sis jeste nevsim, jak SQL v realite funguje. Kupodivu i velmi drobna zmena zapisu ma zcela zasadni vliv na vykon a rychlost dotazu.
SQL používám k obživě už od dob kdy u Oracle vydali verzi databáze 8.0 jako novinku, takže si myslím že jsem si za tu dobu už stačil všimnout jak SQL v realitě funguje. Dovolte mi tedy opravit vaše chybné tvrzení, správně to má znít "Kupodivu i velmi drobna zmena zapisu může mít zcela zasadni vliv na vykon a rychlost dotazu." - nikde totiž není záruka že změna v zápisu dotazu skutečně bude mít vliv na výkon a rychlost dotazu, ba právě naopak: databáze se i přepsaný dotaz může rozhodnout vykonat přesně stejně jako ten původní, viz příklad níže.
Subselect je pak v 90% zdaleka nejhorsi mozna varianta vubec.
To záleží na konkrétní databázi. Například u Oracle jsou tyto dva dotazy prováděny naprosto stejně, za předpokladu že sloupec b v tabulce b je nut null:
select a.a from a where a.a not in (select b.b from b);
select a.a from a where not exists (select 1 from b where a.a=b.b);
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.
-
Nejspis sis jeste nevsim, jak SQL v realite funguje. Kupodivu i velmi drobna zmena zapisu ma zcela zasadni vliv na vykon a rychlost dotazu. Subselect je pak v 90% zdaleka nejhorsi mozna varianta vubec.
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.
Dufam ze nahradenie "cosi is null" vyrazom "isnull(cosi,0) = 0" nepatri medzi tvoje standartne programove riesenia....
Ak hej... lopata ti pristane viac....
-
Nejspíš jste si ještě nevšimnul že SQL je deklarativní jazyk, takže to jak zapíšete dotaz nemá přímý vliv na to jak ho databáze provede - volba execution planu v databázi je celkem komplikovaná věc, takže tvrdit že ten korelovaný poddotaz bude databáze provádět jinak (a dokonce náročněji) než ty joiny podle mě je naprosto nepodložená spekulace.
Nejspis sis jeste nevsim, jak SQL v realite funguje. Kupodivu i velmi drobna zmena zapisu ma zcela zasadni vliv na vykon a rychlost dotazu.
SQL používám k obživě už od dob kdy u Oracle vydali verzi databáze 8.0 jako novinku, takže si myslím že jsem si za tu dobu už stačil všimnout jak SQL v realitě funguje. Dovolte mi tedy opravit vaše chybné tvrzení, správně to má znít "Kupodivu i velmi drobna zmena zapisu může mít zcela zasadni vliv na vykon a rychlost dotazu." - nikde totiž není záruka že změna v zápisu dotazu skutečně bude mít vliv na výkon a rychlost dotazu, ba právě naopak: databáze se i přepsaný dotaz může rozhodnout vykonat přesně stejně jako ten původní, viz příklad níže.
Subselect je pak v 90% zdaleka nejhorsi mozna varianta vubec.
To záleží na konkrétní databázi. Například u Oracle jsou tyto dva dotazy prováděny naprosto stejně, za předpokladu že sloupec b v tabulce b je nut null:
select a.a from a where a.a not in (select b.b from b);
select a.a from a where not exists (select 1 from b where a.a=b.b);
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.
Lenze s HLUPO navrhnutym príkazom si ani najlepsia DB na svete nepomoze.
-
Lenze s HLUPO navrhnutym príkazom si ani najlepsia DB na svete nepomoze.
Kupodivu už i to jsem zažil - SQL dotaz od dodavatele na první pohled vypadal příšerně, ale když jsem si zkontroloval jeho execution plan v reálné databázi tak byl rozumný.
-
Lenze s HLUPO navrhnutym príkazom si ani najlepsia DB na svete nepomoze.
Kupodivu už i to jsem zažil - SQL dotaz od dodavatele na první pohled vypadal příšerně, ale když jsem si zkontroloval jeho execution plan v reálné databázi tak byl rozumný.
Nemal som na mysli efektivitu.
-
Lenze s HLUPO navrhnutym príkazom si ani najlepsia DB na svete nepomoze.
Kupodivu už i to jsem zažil - SQL dotaz od dodavatele na první pohled vypadal příšerně, ale když jsem si zkontroloval jeho execution plan v reálné databázi tak byl rozumný.
No tak to pak ale nebyl hloupě navržený SQL dotaz?
-
Tak ještě jednou jinými slovy: SQL je deklarativní jazyk což znamená že progamátor nemá přímou kontrolu nad tím jak se budou složitější dotazy (u kterých je víc než jedna triviální možnost) provádět. To je neoddiskutovatelný fakt.
To je naopak zcela oddiskutovatelný fakt. Když napíšu "select * from a, b, c" tak mám naprostou jistotu, že se mi v explain planu neobjeví tabulky "d", "e" a "f". Že se tam možná neobjeví ani a, b nebo c je věc jiná. A teď se vraťme k původní úloze - jedna verze projde tabulku X s milionem záznamů ty vyfiltruje a sdruží. Druhá verze vezme tabulku Y s tisícem záznamů a ke každému zkusí exists nad tabulkou X s milionem záznamů. Jasně že moderní databáze neprovede 1000 x 1000000 operací, ale to je jen díky kvalitě té databáze. První verze ale v žádném případě, i kdyby se databáze ukrutně špatně vyspala, nebude pracovat nad miliardovým kartézským součinem. Prostě v tom dotazu tabulka Y není a proto se nad ní nic provádět nebude. Tečka.
-
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..."
-
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.
-
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).
-
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.
-
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).
-
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ší...
-
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.
-
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.
-
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.
-
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.
-
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.
-
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/
-
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?
-
Zacal asi opravovat svoje projekty :)
-
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...
-
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.
-
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.
Nj, ty zas nechapes, ze ta fce je pomalejsi, i kdyz ji predhodis primo cisla, zeano. Vubec nemusis lizt do zadnych tabulek.
Jinak receno:
select floor(cast(getdate() - '2014-12-01' as float))
select datediff(dd,'2014-12-01', getdate())
Vrati oboje totez (neboli pocet dnu mezi nastavenym datem a soucasnym), ale v prvnim pripade je to nekolikanasobne rychlejsi. A to presto, ze to vizuelne vypada slozitejs.
-
dobre rano,
zalezi na mnoha vecech jak bude optimalizator vyhodnocovat sql,
jsou oba sloupce indexovane jednim indexem?
- pokud ano, tak to bude bud fast full index nebo jen index scan (zalezi na strukture indexu)
- pokud ne tak se bude vzdy provadet full table scan, serazeni a vyber unikatnich zaznamu, zde zalezi na velikosti resultset a na konfiguraci db enginu
vhodnost struktury tabulky/tabulek (zda normalizovana ci denormalizovana) musi vedet autor podle pozadavku
pri popisovanem stavu by mel byt nejlepsi select distinct, pokud jde o "velkou" tabulku a casto pouzivany dotaz, pak by bylo vhodnejsi pouzit mview
apion
-
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.
Nj, ty zas nechapes, ze ta fce je pomalejsi, i kdyz ji predhodis primo cisla, zeano. Vubec nemusis lizt do zadnych tabulek.
Jinak receno:
select floor(cast(getdate() - '2014-12-01' as float))
select datediff(dd,'2014-12-01', getdate())
Vrati oboje totez (neboli pocet dnu mezi nastavenym datem a soucasnym), ale v prvnim pripade je to nekolikanasobne rychlejsi. A to presto, ze to vizuelne vypada slozitejs.
Stale je to o tom co som napisal.... floor, casting a odpocitanie si vie lahko zoptimalozovat pretoze su to trivialne funkcie. Kdezto datediff je jeden moloch ktory zalezi na roznych parametroch
-
j: Zjisti si něco o stable, volatilních a immutable funkcích, např. tady:
http://www.postgresql.org/docs/8.1/static/xfunc-volatility.html
Databáze, která takto funkce nerozlišuje, má všechny v kategorii volatile....
To je celé.
Volbou volatile či nevolatile funkce pak samozřejmě člověk může plán velmi ovlivnit včetně využití indexů - ale to patří mezi základní databázařskou latinu, to není žádná temná magie.