Databáze DuckDB (Wikipedie) dospěla po 6 letech do verze 1.0.0.
Intel na veletrhu Computex 2024 představil (YouTube) mimo jiné procesory Lunar Lake a Xeon 6.
Na blogu Raspberry Pi byl představen Raspberry Pi AI Kit určený vlastníkům Raspberry Pi 5, kteří na něm chtějí experimentovat se světem neuronových sítí, umělé inteligence a strojového učení. Jedná se o spolupráci se společností Hailo. Cena AI Kitu je 70 dolarů.
Byla vydána nová verze 14.1 svobodného unixového operačního systému FreeBSD. Podrobný přehled novinek v poznámkách k vydání.
Společnost Kaspersky vydala svůj bezplatný Virus Removal Tool (KVRT) také pro Linux.
Grafický editor dokumentů LyX, založený na TeXu, byl vydán ve verzi 2.4.0 shrnující změny za šest let vývoje. Novinky zahrnují podporu Unicode jako výchozí, export do ePub či DocBook 5 a velké množství vylepšení uživatelského rozhraní a prvků editoru samotného (např. rovnic, tabulek, citací).
Byla vydána (𝕏) nová verze 7.0 LTS open source monitorovacího systému Zabbix (Wikipedie). Přehled novinek v oznámení na webu, v poznámkách k vydání a v aktualizované dokumentaci.
Organizace Apache Software Foundation (ASF) vydala verzi 22 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Společnost AMD na veletrhu Computex 2024 představila (YouTube) mimo jiné nové série procesorů pro desktopy AMD Ryzen 9000 a notebooky AMD Ryzen AI 300.
OpenCV (Open Source Computer Vision, Wikipedie), tj. open source multiplatformní knihovna pro zpracování obrazu a počítačové vidění, byla vydána ve verzi 4.10.0 . Přehled novinek v ChangeLogu. Vypíchnout lze Wayland backend pro Linux.
-------+-----+------+--------------+----------+-------+-----------------+-----+--------------+ |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 | +------+------------+--------------+----------+-------+-----------------+-----+--------------+
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, DatMJinak 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
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ě?
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: