Training Solo (Paper, GitHub) je nejnovější bezpečnostní problém procesorů Intel s eIBRS a některých procesorů ARM. Intel vydal opravnou verzi 20250512 mikrokódů pro své procesory.
Byla vydána nová verze 25.05.11 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Nejnovější Shotcut je již vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Svobodný elektronický platební systém GNU Taler (Wikipedie, cgit) byl vydán ve verzi 1.0. GNU Taler chrání soukromí plátců a zároveň zajišťuje, aby byl příjem viditelný pro úřady. S vydáním verze 1.0 byl systém spuštěn ve Švýcarsku.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 209. brněnský sraz, který proběhne tento pátek 16. května od 18:00 ve studentském klubu U Kachničky na Fakultě informačních technologií Vysokého učení technického na adrese Božetěchova 2/1. Jelikož se Brno stalo jedním z hlavních míst, kde se vyvíjí open source knihovna OpenSSL, tentokrát se OpenAlt komunita potká s komunitou OpenSSL. V rámci srazu Anton Arapov z OpenSSL
… více »GNOME Foundation má nového výkonného ředitele. Po deseti měsících skončil dočasný výkonný ředitel Richard Littauer. Vedení nadace převzal Steven Deobald.
Byl publikován přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie) za uplynulé dva měsíce. Servo zvládne už i Gmail. Zakázány jsou příspěvky generované pomocí AI.
Raspberry Pi Connect, tj. oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče, byla vydána v nové verzi 2.5. Nejedná se už o beta verzi.
Google zveřejnil seznam 1272 projektů (vývojářů) od 185 organizací přijatých do letošního, již jednadvacátého, Google Summer of Code. Plánovaným vylepšením v grafických a multimediálních aplikacích se věnuje článek na Libre Arts.
Byla vydána (𝕏) dubnová aktualizace aneb nová verze 1.100 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.100 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.5.
nasledujici select funguje ale trva uzasnych 22 vterin
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
SELECT count(idz) AS dluzniku FROM `zakaznici`
WHERE datum_z<'2005-12-01' AND idz NOT IN
(SELECT zakaznik FROM `platby_2006`
WHERE zakaznik NOT LIKE -1 AND DATE_FORMAT(datum_s,'%m')=06)
takze db programator neco ve smyslu a trvani dotazu je <2 vteriny coz je uzasne :)
$x=mysql_query("SELECT zakaznik FROM `platby_2006` WHERE zakaznik NOT LIKE -1 AND DATE_FORMAT(datum_s,'%m')=06");
SELECT count(idz) AS dluzniku FROM `zakaznici` WHERE datum_z<'2005-12-01' AND idz NOT IN ($x);
Vysledkem $x je seznam cosel 1,2,3,... a pokud jich je vic nez 999 tzn trba 1000 mysql hrde zahlasi 0 rows coz je naprosto dokonala pitomost.
Takze dotaz zni kde se nastavuji tyhle limity??? v mysql ve verzi 5.0.18rc2 ten limit neni ve verzi 5.0.22 ano prosel jsem changelogy mezi verzema ale nic zvlastniho zdrojaky jsem nezkoumal... :)takze db programator neco ve smyslu a trvani dotazu je <2 vteriny coz je uzasne
Je to tím vedrem nebo ta věta není česky? :-)
Mimochodem, co to, proboha, znamená 'zakaznik NOT LIKE -1'?
Dost bych se ohradil proti tomu, že autora onoho kódu označujete za "db programátora". To je, jako byste Petra Novotného nazval mistrem televizní zábavy...
select count(IDZ) as DLUZNIKU from ZAKAZNICI Z
left join PLATBY_2006 P on P.ZAKAZNIK=Z.IDZ
and DATUM_S>='2006-06-01' and DATUM_S<'2006-07-01'
where Z.DATUM_Z<'2005-12-01' and P.IDZ is null
Ten server, na kterém to spouštíte, asi nemá nožičky, že? Protože kdyby je měl, tak by vyběhl z racku a nakopal by vás do prdele.
Zkuste třeba něco jako
SELECT count(idz) AS dluzniku FROM zakaznici LEFT JOIN platby_2006 ON (idz=zakaznik) WHERE datum_z<'2005-12-01' AND DATE_FORMAT(datum_s,'%m')=06 AND zakaznik IS NOT NULL
(o optimálnosti podmínky DATE_FORMAT(datum_s,'%m')=06 ani nemluvě).
Rovny si být mohou, otázka spíš je, zda jsou si ekvivalentní. 
Řekl bych, že celkově to nemá cenu příliš komentovat...
Ale ona za to MySQL opravdu nemůže Z databázových systémů jsem rovněž odkojen MySQL (když teda nepočítám FoxBase a FoxPro) a s rozlišováním a korektním používáním datových typů kupodivu nemám problém. Ovšem ono to bude dáno tím, že se striktně typovými jazyky jsem pracoval už v dobách, kdy o MySQL nebylo ani slechu ani vidu - a zažité návyky si nehodlám nechat zkazit žádnými beztypovými nebo nedejbože autotypovými věcmi jako MySQL či PHP
Promiňte, ale pokud nezačnete používat aspoň interpunkci.vs
Dole jsem zopakoval dotaz i pro vás doufám v nakopnutí správným směrem.A teď si vyber: "dole jsem zopakoval dotaz i pro vás, doufám v nakopnutí správným směrem" nebo "dole jsem zopakoval dotaz, i pro vás doufám v nakopnutí správným směrem"?
Uznavam prehnal jsem to.
Ale stejne porad nevim jak obejit limit na NOT IN (..), ktery ma 999 polozek.
BTW tu dokumentaci jsem opravdu precetl a zkousel nastavovat ruzne limity na serveru.
Klientem (obyc mysql v konzoli serveru - neladim tu aplikaci) to neni, je to chyba serveru, stejny klient a server verze 5.0.18 to funguje bezproblemu.
NOT IN (…) považuji za nepravděpodobné. Ale i kdybych to vyzkoušel na verzi 4.1.14, kterou tu mám, a tam ten limit nebyl, bude vám ta informace k ničemu.
Nemá ten klient třeba nastaven nějaký maximální počet záznamů, bufferování apod.? Chová se to stejně i když klienta spustíte mysql --quick?
Ten dotaz ale určitě jde přepsat na outer join, se kterým si databáze dokáže poradit daleko líp – např. Michal Kubeček zde jeden napsal.
not in (...)' s 999 hodnotami je vlastně 1000 podmínek spojených pomocí and. Samozřejmě nevím nic o tom, jak ten parser u MySQL vypadá a jak vypadá jeho interní reprezentace dotazu, ale dokážu si představit, že to může být docela vážný problém.
selecty nepřevádí na nevnořený select s vloženými hodnotami ani parser MySQl… I kdyby někde něco takového bylo, nebude to 1000, ale 256, 65536 nebo i 1024. Ale těch 1000 – to vypadá na hodnotu pro lidi, ti mají ten divný zvyk používat desítkovou soustavu
ja by som sa pri konstantach necudoval. okruhle cisla typu 64 su vlastne len isty typ prezitku, odlisenia sa, take cislo 314 by splnilo ucel rovnako
Aha, a mám to samozřejmě špatně, místo IS NOT NULL tam patří IS NULL.
DATE_FORMAT(datum_s,'%m')=06? Jediné co mě napadá je, že daná funkce nejspíše vrací string takže ta 06 by měla být spíše '06'. Do databází pronikám a rád se nechám poučit.
Děkuji
datum_s between '2006-06-01' and '2006-07-01'.nevraviac tom, ze existuje tabulka platby_2006, potom bude platby_2007, kde dany problem pravdepodobne ziska na zlozitosti, a tak dalej.
'06' = 6" bude splněn nebo ne (asi bude záležet na tom, kterým směrem se bude provádět ta implicitní konverze).
Pro každý řádek tabulky se pole datum_s z typu DATETIME (nebo jiného podobného) explicitně přeformátovává na string, a ten se pak s něčím porovnává. Z hlediska výkonu je to naprosto zoufalé, protože pokud byste napsal podmínku datum_s>='2006-06-01' and datum_s<'2006-07-01', provede parser jednou na začátku dotazu konverzi těch literálů na DATETIME a query už pak nativně porovnává DATETIME typy, což je MNOOOOHEM rychlejší, nemluvě o tom, že inteligentní člověk (tváří v tvář takové podmínce) si na daný sloupec vytvoří index, a pak je ten dotaz MNOHOŘÁDOVĚ rychlejší.
Funkční rozdíl je pravda v tom, že konstrukce s DATE_FORMATem vybere data z 6. měsíce libovolného roku, ta druhá konstrukce jen ze 6. měsíce 2006 - ale z kontextu je zjevné, že to nevadí.
A pochopitelně se ten výsledek DATE_FORMAT musí porovnávat s "06" a nikoliv s 06. V červnu to sice funguje, ale konkrétně v srpnu a září to fungovat nebude - což si laskavý čtenář dovodí jako cvičení
CREATE TABLE `test`.`speed_test` (
`Id` int(11) NOT NULL auto_increment,
`datum` datetime NOT NULL,
`text` varchar(255) CHARACTER SET 'utf8' COLLATE 'utf8_czech_ci' NOT NULL,
`cislo` int(11) NOT NULL DEFAULT '0',
`dlouhy_text` mediumtext CHARACTER SET 'utf8' COLLATE 'utf8_czech_ci' NOT NULL,
PRIMARY KEY (`Id`)
) ENGINE=MyISAM CHARACTER SET='utf8';
vložil do ní přibližne milion náhodných záznamů kde datum bylo v rozmezí 1.1.2000 00:00:00 až 28.12.2010 23:59:59 (texty a čísla byly taktéž náhodné) a po té aplikoval následující dotazy...
select count(id) from speed_test where DATE_FORMAT(datum,'%m')="06" AND DATE_FORMAT(datum,'%Y')="2006";
01:04
select count(id) from speed_test where datum>='2006-06-01 00:00:00' and datum<'2006-07-01 00:00:00';
01:04
select count(id) from speed_test where MONTH(datum)="06" AND YEAR(datum)="2006";
01:04
číslo pod dotazem vždy udává pruměrný čas z 5 průchodů
No jak vidíte tak výsledky jsou naprosto totožné, takže by mě zajímalo jak je to možné. Pochopitelně z toho nelze příliš usuzovat (nejedné se o skutečnou databázi, nejde o skutečný provoz, na pozadí mě běžely další procesy apod.) ale i tak jsem čekal alespoň nejaký rozdíl...
MONTH(datum) a YEAR(datum) převádět na řetězec a pak porovnávat řetězce. Pokud chcete opravdu porovnávat výkon kvůli optimalizaci, porovnejte (samozřejmě s indexem) varianty
MONTH(datum)=6 AND YEAR(datum)=2006a
datum >= '2006-06-01' AND datum <= '2006-06-30'
Výsledky jsou naprosto totožné proto, že (pokud jste to nezkoušel na nějaké 386 s 8MB paměti) po prvním dotazu z toho vašeho "banchmarku" se ocitla celá tabulka v paměti a optimalizačních hashích MySQL.
To je všechno. Když se mé ženy zeptáte osmkrát po sobě na to samé, odpoví vám osmkrát stejně. Když se jí každý den zeptáte na to samé osm dní po sobě, odpoví vám každý den jinak, a ještě nad tím bude dlouho přemýšlet.
I přesto jsem si jist, že moje žena je inteligentnější než MySQL.
Přeháněl jsem. Problém je v tom, že jste se třemi různě pitomými způsoby ptal na to samé. O pár komentářů výš vám někdo doporučoval indexovat ten tázaný sloupec, to jste nezkusil. Co vám mám odpovědět? Já nehodlám soudit, který z těch tří vašich dotazů je míň idiotský (slovo jako "lepší" zde nelze použít) a je mi zcela fuk, jak dlouho trvají. Zkuste napsat OPTIMALIZOVANÝ dotaz, s použitím indexů, a porovnejte ho s těmi ostatními.
Pak se můžeme bavit dál - ale srovnávat tři pičoviny a řešit, která z nich je míň hnusná, nezlobte se, to mě nebaví. V této diskuzi zaznělo hodně užitečných postřehů, přeberte si je. Já se nehodlám bavit o způsobech, jak se co nejlépe škrabat pravou nohou za levým uchem.
ačkoli by to i bez toho indexování mělo být "MNOOOOHEM rychlejší"To tady nikdo netvrdil. Je to asi stejné tvrzení, jako "auto i bez motoru musí být mnohem rychlejší". Indexy u databáze nejsou "jen tak něco navíc", indexy jsou podstata databáze. Druhou podstatnou částí je optimalizátor dotazů (proto je tak důležité databázi správně sdělit, co vlastně chcete najít). A to je skoro vše, všechno ostatní už jsou takové třešničky na dortu.
SELECT count(idz) AS dluzniku FROM `zakaznici`
WHERE datum_z<'2005-12-01' AND idz NOT IN
(SELECT zakaznik FROM `platby_2006`
WHERE zakaznik NOT LIKE -1 AND DATE_FORMAT(datum_s,'%m')=06)
No a teď to co se snaží udělat programator
$result=mysql_query("SELECT zakaznik FROM `platby_2006` WHERE zakaznik NOT LIKE -1 AND DATE_FORMAT(datum_s,'%m')=06");
#...tady si to parsne z resultu do $x="1,1,2,3,4,5,6"
#...
SELECT count(idz) AS dluzniku FROM `zakaznici` WHERE datum_z<'2005-12-01' AND idz NOT IN ($x);
no takže snad takto
Tahle query trvá 2 vteřin
s/2/20/
in a not in su v podstate porovnavanie kazdy s kazdym. A rozdiel v pripade subselectu pripisujem roznym datovym strukturam, predpokladam, ze taku trivialnu chybu, ako spustanie subselectu pre kazdy testovany riadok by si ani v mysql nedovolili.mysql, pokial viem, nema ziadne limity, o ktorych by bolo treba pisat. Co sa tyka max dlzke prikazu, v davnych casoch 4.0 sa odporucalo zvacsit premennu net_buffer_length
EXPLAIN
SELECT * from `zakaznici` z LEFT JOIN (select zakaznik FROM `platby_2006` WHERE zakaznik NOT LIKE -1 AND DATE_FORMAT(datum_s,'%m')=06 ) tmp_platby on z.idz = tmp_platby.zakaznik where zakaznik IS nullPS: chci věšteckou kouli
... WHERE zakaznik NOT LIKE -1 ...
a
...DATE_FORMAT(datum_s,'%m')=06 ...
a tohle je mi taky značně podezřelé ....
... ON z.idz = tmp_platby.zakaznik WHERE zakaznik IS NULL
no trik je v tom, ze se dela left join se subselectem o dost rychlejsi nez na cele table :))),
trik dva je to, ze se skutecne vyberou ti kteri maji null, ale jsou soucasti toho joinu...
podstata problemu tkvi v tom ze vysledek jestli zakaznik patri tam ci onam se zjisti az z toho joinu kteri je lepsi delat na mene datech protoze misto 40 s trva 0,2s coz je nezanedbatelny rozdil...
a ted me bijte vypada to hnusne, ale je to rychle
ten datum je blbje ulozen takze pracuju s tim co je
NOT LIKE -1 je tam kvuli zhovadilosti, kterou me vysvetloval auto navrhu :) prej ze tam AAAANO mohlo bejt neco hezciho
K.
Tiskni
Sdílej:
