Fedora 40 release party v Praze proběhne v pátek 17. května od 18:30 v prostorách společnosti Etnetera Core na adrese Jankovcova 1037/49, Praha 7. Součástí bude program kratších přednášek o novinkách ve Fedoře.
Stack Overflow se dohodl s OpenAI o zpřístupnění obsahu Stack Overflow pro vylepšení OpenAI AI modelů.
AlmaLinux byl vydán v nové stabilní verzi 9.4 (Mastodon, 𝕏). S kódovým názvem Seafoam Ocelot. Přehled novinek v příspěvku na blogu a v poznámkách k vydání.
Před 50 lety, 5. května 1974 v žurnálu IEEE Transactions on Communications, Vint Cerf a Bob Kahn popsali protokol TCP (pdf).
Bylo vydáno do češtiny přeložené číslo 717 týdeníku WeeklyOSM přinášející zprávy ze světa OpenStreetMap.
Byla vydána (Mastodon, 𝕏) nová stabilní verze 2.10.38 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP je již k dispozici také na Flathubu.
Google zveřejnil seznam 1220 projektů od 195 organizací (Debian, GNU, openSUSE, Linux Foundation, Haiku, Python, …) přijatých do letošního, již dvacátého, Google Summer of Code.
Na základě DMCA požadavku bylo na konci dubna z GitHubu odstraněno 8535 repozitářů se zdrojovými kódy open source emulátoru přenosné herní konzole Nintendo Switch yuzu.
Webový prohlížeč Dillo (Wikipedie) byl vydán ve verzi 3.1.0. Po devíti letech od vydání předchozí verze 3.0.5. Doména dillo.org již nepatří vývojářům Dilla.
O víkendu probíhá v Bostonu, a také virtuálně, konference LibrePlanet 2024 organizovaná nadací Free Software Foundation (FSF).
-------+-----+------+--------------+----------+-------+-----------------+-----+--------------+ |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: