Jihokorejská kryptoměnová burza Bithumb přiznala vážné selhání interních systémů, které ji vystavilo riziku sabotáže a nezabránilo chybné transakci v hodnotě přes 40 miliard dolarů (814 miliard Kč). Druhá největší kryptoměnová burza v Koreji minulý týden při propagační akci omylem rozeslala zákazníkům zhruba 620 000 bitcoinů místo 620 000 wonů (8700 Kč). Incident vyvolal pokles ceny bitcoinu o 17 procent. Většinu
… více »Google Chrome 145 byl prohlášen za stabilní. Nejnovější stabilní verze 145.0.7632.45 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Zpátky je podpora grafického formátu JPEG XL, viz Platform Status. Odstraněna byla před třemi lety. Nový dekodér JPEG XL jxl-rs je napsán v Rustu. Zobrazování JPEG XL lze vyzkoušet na testovací stránce. Povolit lze v nastavení chrome://flags (Enable JXL image format).
Byla vydána nová verze 1.26 programovacího jazyka Go (Wikipedie). Přehled novinek v poznámkách k vydání.
CrossOver, komerční produkt založený na Wine, byl vydán ve verzi 26. Přehled novinek v ChangeLogu. CrossOver 26 vychází z Wine 11.0, D3DMetal 3.0, DXMT 0.72, Wine Mono 10.4.1 a vkd3d 1.18. Do 17. února lze koupit CrossOver+ se slevou 26 %.
KiCad je nově k dispozici také jako balíček ve formátu AppImage. Stačí jej stáhnout, nastavit právo na spouštění a spustit [Mastodon, 𝕏].
Šenčenská firma Seeed Studio představila projekt levného robotického ramena reBot Arm B601, primárně coby pomůcky pro studenty a výzkumníky. Paže má 6 stupňů volnosti, dosah 650 mm a nosnost 1,5 kilogramu, podporované platformy mají být ROS1, ROS2, LeRobot, Pinocchio a Isaac Sim, krom toho bude k dispozici vlastní SDK napsané v Pythonu. Kompletní seznam součástek, videonávody a nejspíš i cena budou zveřejněny až koncem tohoto měsíce.
… více »Byla vydána nová verze 36.0, tj. první stabilní verze nové řady 36, svobodného multimediálního centra MythTV (Wikipedie). Přehled novinek a vylepšení v poznámkách k vydání.
Byl vydán LineageOS 23.2 (Mastodon). LineageOS (Wikipedie) je svobodný operační systém pro chytré telefony, tablety a set-top boxy založený na Androidu. Jedná se o nástupce CyanogenModu.
Od března budou mít uživatelé Discordu bez ověření věku pouze minimální práva vhodná pro teenagery.
Evropská komise (EK) předběžně shledala čínskou sociální síť pro sdílení krátkých videí TikTok návykovým designem v rozporu s unijním nařízením o digitálních službách (DSA). Komise, která je exekutivním orgánem Evropské unie a má rozsáhlé pravomoci, o tom informovala v tiskovém sdělení. TikTok v reakci uvedl, že EK o platformě vykreslila podle něj zcela nepravdivý obraz, a proto se bude bránit.… více »
30.4.2008 15:27
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
-------+-----+------+--------------+----------+-------+-----------------+-----+--------------+ |select|table|type |possible_keys |key |key_len|ref |rows |Extra | -------+-----+------+--------------+----------+-------+-----------------+-----+--------------+ |SIMPLE|Recor|ALL |PRIMARY,CL_IDX|[NULL] | [NULL]|[NULL] |65621|Using filesort| |SIMPLE|Clien|eq_ref|PRIMARY |PRIMARY | 4|Records.ClientNr | 1| | |SIMPLE|VChro|ref |Client_idx |Client_idx| 5|Clients.ClientNr | 7|Using where | |SIMPLE|Chron|ref |Record_idx |Record_idx| 5|Records.RecordNr | 13|Using where | +------+------------+--------------+----------+-------+-----------------+-----+--------------+
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
SELECT
Records.ClientNr,
Clients.Name AS Nazev,
LEFT(Clients.VSB,2) AS Obch,
COUNT(DISTINCT Records.RecordNr) AS Spisy,
DATE_FORMAT(Recdate,'%Y%m') AS DatM,
MAX(CASE WHEN VChrontable.Kuerzel = 'V23' THEN VChrontable.Datum END) AS DatSml,
SUM(CASE WHEN Chrontable.Kuerzel LIKE 'RG%' AND Chrontable.Kuerzel <> 'RGKČX'
OR Chrontable.Kuerzel LIKE 'Z00%' THEN Chrontable.Betrag ELSE 0 END) AS Suma
FROM
Records,
Chrontable,
Clients,
VChrontable
WHERE
Records.RecordNr = Chrontable.RecordNr
AND Records.ClientNr = Clients.ClientNr
AND Clients.ClientNr = VChrontable.ClientNr
GROUP BY Records.ClientNr, DatM
Jinak mi není jasné, co tím dotazem vlastně chcete zjistit. Ty podmínky v agregačních funkcích vypadají divně (proč nejsou ve WHERE?), používat za SELECTem mimo agregační funkce sloupce, které nejsou v GROUP BY, by vám v jiné databázi než MySQL neprošlo (a bez pohledu do dokumentace nedokážu určit, jak moc náhodně bude MySQL vybírat hodnoty pro ty sloupečky). Teď mne ještě praštilo do očí – pokud je DatM v GROUP BY opravdu ten formátovaný řetězec, pak chudák databáze – na to nemůže použít žádný index. A jestli se nepletu tohle by vám opět u jiných databází neprošlo.
group by 1, 5 (podľa prvého a piateho stĺpca)
mne osobne sa nepáči:
- spomínané chýbajúce stĺpce v group by
- distinct v count
- or v SUM
- chýbajúce else v MAX
podmienky v agregačných funkciách majú zmysel, aj keď podivný (návrh databázy smrdí nemčinou, tam sa podivnosti očakávať dajú)
Records(RecordNr long,ClientNr long, Recdate date) Chrontable(Kuerzel varchar,Betrag double) Clients(ClientNr long, VSB varchar) VChrontable(ClientNr long, Kuerzel varchar, Datum date) a co chci zjistit: ClientNr, počet RecordNr, k nim součet RG (v mém dotazu AS Suma), první dva znaky z Clients.VSB, VChrontable.datum pro Kuerzel = 'V23' (pokud existuje) seskupeno podle ClientNr a podle měsíce z Records.Recdate (yyyymm) nebo jinými slovy počet Records.RecordNr, součet Chrontable.Betrag kde RecordNr=Records.RecordNr a kde Kuerzel LIKE 'RG%' ... za každý měsíc dle Records.Recdate a k tomu VChrontable.Datum kde je Kuerzel = 'V23' a k tomu Clients.VSB
where. Podle jmen sloupcu (a tvojeho where) odhaduji, ze by to mohlo byt
FROM Records join Clients on Clients.ClientNr=Records.ClientNr join VChrontable on VChrontable.ClientNr=Records.ClientNr join Chrontable on Chrontable.Kuerzel=VChrontable.KuerzelA urcite bych se pokusil vyhnout spojeni pres varchar polozku.
SELECT
Records.ClientNr,
select Clients.Name from clients where Records.ClientNr = Clients.ClientNr AS Nazev,
LEFT(Clients.VSB,2) AS Obch,
select ....
DATE_FORMAT(Recdate,'%Y%m') AS DatM,
select ....
select ........
FROM
Records
GROUP BY
Records.ClientNr, DatM
Diky za opravu where) jeste pole Chrontable.Kuerzel=VChrontable.Kuerzel?Chrontable.RecordNr a ja si nevsiml, ze to podle neho mas spojene ve where."Ty podmínky v agregačních funkcích vypadají divně (proč nejsou ve WHERE?), používat za SELECTem mimo agregační funkce sloupce, které nejsou v GROUP BY, by vám v jiné databázi než MySQL neprošlo"MySQL něco takového opravdu sežere a ani nepípne? Není to "poněkud" proti SQL normě?
Ale už si nepamatuju přesně, o co šlo.
(Možná že v SQL normě jsou jen ty agregovaný sloupce a sloupce z GROUP BY, možná má databáze povolený inferovat další jednoznačný buňky - tím už si nejsem jistej.)
Což Ti asi vysvětlovat nemusím, ale jsem si skoro jistý, že se Ti stalo právě tohle - taky se mi občas stane, že na to zapomenu, ale nikdy by mě nenapadlo, že může existovat ("relační", zde v uvozovkách ) databáze, která na to neupozorní. BTW, pokud náhodou skutečně potřebuješ skupinu hodnot čistě do výsledku, ve Firebirdu 2.1 přibyla agregační fce LIST( [ {ALL | DISTINCT } ] <value_expression> [ ',' <delimiter_value> ] ), která umí "atomizovat" sloupce do seznamu prezentovatelného uživateli. Vrací to řetězec. Asi záleží na klientské straně, ale chvílema se to může hodit, třeba v ISQL.
Formátování by opravdu hodně pomohlo na čitelnosti.
Zkusil bych následující kroky ke zjištění co dělá problém:
Tiskni
Sdílej:
