SQL dotaz bez opakování výsledků

[j]

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.

[Reklama]

[Kolemjdoucí]

Jsi vedle jak ta jedle, vyjeď si exekuční plán. (Leda že bys používal nějakou hodně historickou DB).

[Někdo]

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.

[karel]

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 na to člověk časem příjde jak to v realném životě s tou deklarativností vlatně je

[j]

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.

[Reklama]

[Karel (jiný)]

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.

[Někdo]

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.

[Někdo]

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.

[NooN]

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....

[NooN]

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. 

[Někdo]

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ý.

[NooN]

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.

[Makovec]

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?

[Karel (jiný)]

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.

[NooN]

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..."