Dotaz: select z databaze

[Peta]

Ahojte, chci vybrat z databaze tabulku, ale tak, aby ty data byly setrizene podle jednoho elementu. Nejdrive aby byly radky tabulky, ve kterych je tento element null a pote zbytek tech elementu, ve kterych ma tento element nejakou hodnotu.

PS: order by by nejspise sel, ale jak se zachova, kdyz ten element je null a chci ho nejdrive?

Moc diky

---

---

Odpovědi

[peksha]

Zkus
ORDER BY tab.atribut ASC; (vzestupne)
nebo
ORDER BY tab.atribut DESC; (sestupne)
- jedno z toho by Ti to melo dat na zacatku

[Peta]

diky vyzkousim :)

[Michal Kubeček]

Ne nutně.

[krtek007]

ORDER BY řadí NULL buď na začátek nebo na konec, záleží na použité databázi. Pokud vaše databáze řadí zrovna opačně, než jak potřebujete, použijte COALESCE() – jako první hodnotu zadáte sloupec, podle kterého se má řadit. Když bude NULL, použije se druhá hodnota v pořadí – a tam zadejte co nejmenší nebo co největší přípustnou hodnotu (podle toho, kam chcete prázdné hodnoty řadit).

[Tomáš]

order by case when A.x is null then 1 else 0 end, A.x 

Záměnou 0 a 1 můžete řídit zda chcete záznamy s NULL na konci nebo na začátku.

<rejpanec>Žádné šílenosti typu NULL FIRST opravdu nejsou potřeba.</rejpanec>

[Michal Kubeček]

Dají se obejít, ale hodí se - třeba kvůli efektivitě, které ta vaše konstrukce zrovna dvakrát nepřispívá.

[cronin]

Alebo to vyriesit by design a nemat v databaze NULL hodnoty tam, kde sa ocakavaju udaje. Ono vsetky tie NULL, null ci NIL veci su len technicke barlicky ako povedat, ze niekde, kde nieco ma byt, nic nie je. Uplne najhorsie je, ak nejaky null nesie informacnu hodnotu.

Nevravim, ze uvedeny pristup sa ma uplatnovat za kazdych okolnosti. Odporucam sa nad nim vsak aspon zamysliet, kedykolvek je kvoli vyskytu null nutne menit spravanie sa cohosi. Mozno najlepsi pristup, ako dany problem vyriesit, je zariadit, aby vobec nenastal.

[kulik]

<rejpanec>Jiste, proc to psat snadno citelnym deklarativnim zpusobem, kdyz muzu pouzit nekolikrat delsi case a navic tim jeste dosahnout nizsi vykonnosti.</rejpanec>

Jinak v Oracle nulls last|first.

[Tomáš]

Chtěl bych se zeptat z čeho plyne to tvrzení, o snížené výkonosti. Já osobně si dokážu představit pouze jeden velmi specifický a poněkud teoretický případ, kdy by mohla být varianta s case pomalejší než s frází null first/last. A je to tento případ:

1. Vracíte tak veliký počet záznamů, že se výsledek nevejde do paměti.
2. Select musí být nejvýše s frází where (žádné joiny a agregace, případně jen nejjednodušší select)
3. Existuje (b-tree) index nad A.x ( který je řazen podle hodnoty a nikoliv podle hashe ), aby jste mohl využít existujícího řazení na tomto indexu.
4. Optimizer umí v případě fráze where zkomutovat operátory where a order by. Umí takovou optimalizaci vůbec nějaká databáze?

Čitelnost je samozřejmě u nulls first lepší. A přenositelnost? Ta to pěkně odskákala

[Michal Kubeček]

Podmínka 1 je nadbytečná určitě, 2 jedině když je hloupý optimalizátor, 3 není nijak silný předpoklad. Podmínka 4 mi také připadá nadbytečná, pokud se bavíme o porovnání vaší varianty s explicitním nulls first. Přenositelnost u SQL? To je tak trochu utopie všeobecně, jedna praktická konstrukce to nezachrání.

[Tomáš]

Tak ještě jednou a detailněji:

Tvrzení první: pokud před operací sort budete dělat v selectu jinou libovolnou operaci tak si při ní dotyčný case předpočítáte a sort pak může být přeložen téměř úplně stejně jako v případě existence fráze null first/last. Důsledek prvního faktu: Aby bylo možné zlepšení, tak sort musí být první (jediná) operace.

Tvrzení druhé: Aby byl sort s null first efektivnější než case musí dojít k využití btree-indexu (řazeného dle hodnoty nikoliv hashe). Při nevyužití indexu bude složitost stejná v obou případech a to O(n*log n) bez ohledu na počet, a typ vstupů ve frázi order by.

Tvrzení třetí: Aby mělo využití indexu smysl nesmí se vám výsledek vejít do paměti. Pokud se vám tabulka vejde do paměti pak v rámci natažení do paměti uděláte i ten case a dále pokračujete podle tvrzení jedna. Pokud si někdo myslí že přes index to bude i v tomto případě rychlejší, tak je potřeba si uvědomit, že kromě kompletní tabulky musíte do paměti dostat z disku i ten index. O přístupu přes index by možná dalo polemizovat. Já se přikláním k názoru že cena čtení indexu z disku bude větší než cena kompletního třídění v paměti. Bavíme se o třídění relativně malé tabulky, která se vejde do paměti.

Tvrzení čtvrté: Pokud musí být sort první operací (viz tvrzení první a druhé) pak musí komutovat se všemi předchozími operacemi, tak aby se dostal na první místo a bylo možné index využít. Jediný takový případ je, že předchází jediná operace where, protože je to jediná operace, která je schopna zachovat relativní pořadí vět, které vypade ze sort operace. A navíc tato optimalizace musí podporována optimizérem. I zde by možná šlo polemizovat, že lze postavit join algoritmus, který by pořadí zachovával, ale obávám se, že na toto databáze běžně nepodporují.

Otázka zůstává: Z čeho plyne to tvrzení o snížené výkonosti? Rád se nechám poučit.

[Michal Kubeček]

1. hodnotu toho case si předpočítat sice můžete, ale stejně pro jeho hodnoty (ani pro kombinaci s hodnotami sloupce) nebude k dispozici index. Nebude-li tedy optimalizátor natolik chytrý, aby poznal, že vlastně maskujete chybějící nulls first a že tedy můžete použít index na příslušný sloupec (a to téměř jistě nebude), bude výsledek méně efektivní než použití nulls first.

2. Proti této podmínce stále nic nenamítám, ale nepovažuji ji za nijak silný předpoklad. Pokud podle toho sloupce potřebuji často řadit, index si na něm udělám.

3. Za prvé se opíráte o (podle mne chybný) závěr z bodu 1. Za druhé nepočítáte s velmi pravděpodobnou možností, že tabulka je sice malá, ale příslušné stránky (s tabulkou i indexem) už v paměti jsou načteny z dřívějška, kdy se vyhodnocoval jiný dotaz a nebyl tudíž důvod si předpočítat hodnotu toho case-výrazu.

4. Nevidím důvod, proč by join nebo group by musel obecně bránit použití indexu. Pár takových dotazů jsem si vyzkoušel a index se použil, na rozdíl od vaší konstrukce, která využití indexu zabránila zcela spolehlivě.

Kromě toho ve všech bodech automaticky předpokládáte, že rozšíření dotazu o umělý počítaný sloupec a řazení podle kombinovaného klíče místo jednoduchého nepřinese nic nestojí, což je IMHO zcela neopodstatněný předpoklad. Netvrdím, že to výkon sníží nějak zásadně, ale něco to stát bude.

[kulik]

Přenositelnost může být důležitá, ovšem jak kdy. Existuje řada aplikací, kde se přenositelnotst vůbec neřeší, protože je cílem vyždímat z použité platformy maximum právě prostřednictvím jejích specifik (za která se platí často milionové sumy). Typickým příkladem může být datový sklad.

Myslím že zaměňuješ výkon a jakousi obecnou složitost. Stejně tak bych mohl ignorovat descending třídění a aplikovat ascending vždy na vhodně upravenou hodnotu (např. pro čísla triviálně vynásobení -1), a pokud by neexistovaly vhodné indexy, nedošlo by pravděpodobně ke změně asymptotické složitosti, nicméně výkon by byl typicky nižší. I když odhlédneme od indexů (a to je hodně velké odhlédnutí), výpočet výrazu prostě něco stojí, stejně tak uložení sloupce, jistě že to je mnohem méně než např. přístup na disk a rozdíl může být klidně v promile, v principu to ale s "nulls first" může být nejhůře stejné jako s case (v případě "hloupé" databáze, která to dělá analogicky case) a připravuji se o možnost optimalizace u "chytré" databáze. O pokročilé optimalizaci typu query rewrite ani nemluvě. Obecně pokud přepíšu deklarativní věc na procedurální, připravuji se o spoustu optimalizačních možností databázového stroje.

[cronin]

Zariadit, aby sa "prazdne" hodnoty plnili prazdnou ale validnou hodnotou, nie NULL-om. Vyplnit touto hodnotou aktualne NULL-y a pridat pre element obmedzenie NOT NULL. A nikdy viac dany problem nebude potrebne riesit, a to ani technicky (...ako napisat ORDER BY...) ani logicky (...if (value == null) {...} else {...}).

[Filip Jirsák]

Prázdná ale validní hodnota je v databázi právě NULL. Představte si, že mám třeba seznam článků, u kterých chci evidovat datum a čas, kdy byly vydány – ale u některých to prostě nevím. Samozřejmě si tam nebudu vymýšlet nějaké fiktivní datum, ale dám tam NULL. Pokud mám uložené i datum přidání záznamu, můžu pak řadit podle data vydání, pokud jej znám, jinak podle data přidání záznamu.

[cronin]

Prázdná ale validní hodnota je v databázi právě NULL.

Technicky ano. Logicky to tak byt niekedy moze, ale nemusi, a spravidla ani nie je. Stale plati to o barlickach, co som pisal vyssie.

Představte si, že mám třeba seznam článků, u kterých chci evidovat datum a čas, kdy byly vydány – ale u některých to prostě nevím.

Tak to je dost desiva predstava a vasa aplikacia priam krici po poriadnom re-dizajne.

[Filip Jirsák]

Vítejte do reálného světa. Nechci vás moc děsit, ale těch případů, kdy nějaký údaj nevíme nebo dokonce neexistuje je spousta – prostřední jméno, titul před a za jménem, rodné číslo, číslo občanky, SPZ služebního auta, soukromý telefon, datum úmrtí, jméno manžela/manželky a další a další. Řešením není redesign aplikace, ale smířit se s tím, že reálný svět nezapadne dokonale do vašich tabulek se samým NOT NULL a databázi a aplikaci reálnému světu přizpůsobit. Berlička je cpát do datbáze nějaké umělé hodnoty, když tam potřebujeme uložit údaj „zde hodnota není“.

[cronin]

Vítejte do reálného světa.

Profesionalne vyvijam software uz takmer desatrocie. Od reality som vzdialeny tych par hodin, co som prisiel z prace domov. Ak mi niekto povie, ze ma redakcny system, ktory eviduje datum publikacie clankov, ale pre niektore clanky datum nepozna, tak ho do svojho projektoveho timu zaradim len velmi opatrne (slusne povedane). Ale predpokladam, ze si len nestastne zvolil priklad. Na zaver uz len zacitujem sam seba:

Nevravim, ze uvedeny pristup sa ma uplatnovat za kazdych okolnosti. Odporucam sa nad nim vsak aspon zamysliet, kedykolvek je kvoli vyskytu null nutne menit spravanie sa cohosi.

[Filip Jirsák]

Já bych do svého projektového týmu zase nechtěl člověka, který vidí „seznam článků“ a čte „redakční systém“, a který si slovo „nezná“ vykládá jako „vlastně ho znát může“.

[Šangala]

No NULL se asi nevyhneme, ale je otázkou jestli u těchto uvedených, není lepší zvážit prázdný řetězec (mimo datumy) než NULL.
Povolené NULL na sloupec má své opodstatnění, ale čím méně tím lépe :).

[Filip Jirsák]

Třeba rodné číslo je devět nebo deset číslic, tomu ale prázdný řetězec neodpovídá. Navíc dotyčná osoba nemá prostřední jméno, nemá tituly, nemá rodné číslo – to je něco jiného, než že má prostřední jméno „“, to samé pro tituly nebo rodné číslo.

[Šangala]

čekal jsm tuto odpověď :), netvrdím, že se nemá použít NULL, jen bych s ním šetřil :)
Je na zvážení, „“ má v tomto případě stejnou vypovídající hodnotu jako NULL.
Je to jen úhlu pohledu prázdné jméno či titul je v reálném světe bez titulu beze jména, jméno „“ prostě neexistuje.
Jeho neexistenci můžu vyjádřit žádným jménem (jeho nulovou délkou) nebo 3tím stavem NULL, ale pak právě 2. stav „prázdné jméno“ je nedefinovaný stav, není to jméno ani to není absence jména (protože takové hodnoty jméno nemůže nabývat).
Prakticky budeme mít to stejné a záleží jen jak s tím pracujeme a jaké máme kontrolní mechanismy, ale pokud prázdné jméno neznamená něco je zbytečné definovat NULL.
Abych předešel ..., je mi jasné, že hodnoty typu 'N/A' se lépe vyjadřují s NULL, ale to nejdůležitější je zvážit jestli potřebujeme vyjádřit právě takovou hodnotu a ve výsledku nám to nepřidělá práci.
Vůbec nepochybuji o stavu NULL u datumu či časového razítka, pokud chci umožnit nezadáno, tam prostě hodnota '0' je něco jiného.

[Filip Jirsák]

Je to jen úhlu pohledu prázdné jméno či titul je v reálném světe bez titulu beze jména, jméno „“ prostě neexistuje.

Tímhle postupem (jméno „“ neexistuje, tak to použiju místo nezadané/neznámé hodnoty) si koledujete o to, že se vám do databáze brzo dostane někdo, kdo má opravdu prázdné jméno. U toho jména to je sice opravdu dost nepravděpodobné, ale podobné „naschvály“ se dějí poměrně často. takže pokud je někde význam „hodnota neznámá nebo neexistuje“, dám tam raději NULL, i když třeba jinak není přípustný prázdný řetězec nebo tam mají být kladná čísla a tedy bych mohl použít prázdný řetězec nebo 0 či -1. Protože za chvíli si někdo vzpomene, že vlastně prázdný řetězec má taky nějaký význam, nebo že se připouští i nula či záporná čísla.

[Šangala]

Může být :), mívám sám někdy u takovýchto polí NULL povoleno, nicméně vždy se hodně zamyslím jestli opravdu to zlé nepěkné vybočující NULL tam povolím a co přesně říká.
A možná i právě proto co píšete Protože za chvíli si někdo vzpomene…, protože dokud si nevzpomene mám definované stavy (Jméno, Nevyplněno), jakmile si vzpomene definujeme 3. stav (Jméno; Prázdné jméno znamená, že medvěd dorazil; nevyplněno) a musím fčul přizpůsobit aplikační vrstvu. Pokud rozšiřuji mám jednoznačnou úlohu, obraceně už ne.
PS: PhpMyAdmin neumožňoval definici sloupce NULL a default '', už to nějaký pátek umí (od verzí 3.x), bo sem to reklamoval, z toho je patrné, že sám tuto funkcionalitu používám (prázdná řetězec a NULL ≡ dvě informace), nicméně… :)