Změna ve vedení společnosti SUSE. Dosavadní CEO Melissa Di Donato odstoupila. Od 1. května je novým CEO Dirk-Peter van Leeuwen, bývalý Senior Vice President a General Manager ve společnosti Red Hat.
CyberChef je webová aplikace pro analýzu dat a jejich kódování a dekódování, šifrování a dešifrování, kompresi a dekompresi, atd. Často je využívaná při kybernetických cvičeních a CTF (Capture the Flag). Vydána byla nová major verze 10 (aktuálně 10.4.0). Přehled novinek v Changelogu.
UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala Ubuntu Touch OTA-1 Focal založené na Ubuntu 20.04 Focal Fossa.
Společnost Red Hat slaví 30 let.
Ve věku 91 let zemřel izraelský informatik Ja'akov Ziv, spolutvůrce bezztrátových kompresních algoritmů LZ77, LZ78 a LZW (Lempel–Ziv–Welch).
Byla představena nová Arduino deska Arduino UNO R4 s 32bitovým MCU RA4M1 (Arm Cortex-M4). Desku lze zatím získat pouze v rámci early access programu.
Operační systém MidnightBSD, fork FreeBSD optimalizovaný pro desktop s prostředím Xfce, byl vydán ve verzi 3.0. Přehled novinek v poznámkách k vydání.
Na GOG.com běží Spring Sale. Při té příležitosti lze získat zdarma počítačovou hru Neurodeck: Psychological Deckbuilder (ProtonDB).
Alex Ellis upozornil 15. března, že firma Docker se chystala zrušit bezplatný hosting open-source projektů na Docker Hubu. Po vlně odporu se představitelé firmy omluvili a posléze byl původní záměr odvolán.
Ve věku 94 let zemřel Gordon Moore, mj. spoluzakladatel společnosti Intel a autor Moorova zákona.
Řešení dotazu:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
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).
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>
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.
Čitelnost je samozřejmě u nulls first lepší. A přenositelnost? Ta to pěkně odskákala
nulls first. Přenositelnost u SQL? To je tak trochu utopie všeobecně, jedna praktická konstrukce to nezachrání.
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.
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.
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 {...}).
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.
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.
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í“.
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.
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.NULL na sloupec má své opodstatnění, ale čím méně tím lépe :).NULL, jen bych s ním šetřil :)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).NULL.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.NULL u datumu či časového razítka, pokud chci umožnit nezadáno, tam prostě hodnota '0' je něco jiného.
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.
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á.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ě… :)
Tiskni
Sdílej:
