Byla vydána nová verze 4.8.0 programu na úpravu digitálních fotografií darktable (Wikipedie).
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 142 (pdf) a HackSpace 79 (pdf).
Qtractor (Wikipedie) dospěl do verze 1.0.0. Jedná se o Audio/MIDI vícestopý sekvencer.
Byl vydán svobodný kancelářský balík OnlyOffice Docs 8.1. Vedle četných oprav přináší několik funkcí včetně podpory editace textu v PDF a vytváření formulářů v PDF.
Daniel Stenberg, autor nástroje curl, z databáze SteamDB zjistil, že aktuálně 22 734 her na Steamu používá curl.
Společnost Anthropic vydala Claude 3.5 Sonnet, tj. novou verzi své umělé inteligence Claude (Wikipedie). Videoukázky na YouTube. S Claude 3, stejně jak s GPT-3.5, Llama 3 a Mixtral, si lze pokecat bez přihlašování na DuckDuckGo AI Chat.
Byla vydána nová stabilní verze 6.8 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 126. Přehled novinek i s náhledy v příspěvku na blogu a na YouTube. Vypíchnuta jsou vylepšení v integrovaném poštovním klientu.
Příspěvek Aukce domén – měsíc po spuštění na blogu CZ.NIC shrnuje první měsíc provozu Aukce domén .CZ. Aukcemi prošlo celkem 18 174 domén, z toho na 742 z nich byl učiněn alespoň 1 příhoz. Nejdražší aukcí byla na doménu virtualnisidlo.cz s cenou 95 001 Kč, která však nebyla včas uhrazena. Nejdražší aukcí, která byla vydražena i zaplacena je praguecityline.cz s cenovkou 55 600 Kč.
Před 40 lety, 19. června 1984, Bob Scheifler představil první verzi okenního systému X (X Window System). Vycházela z okenního systému W (W Window System).
Desktopové prostředí MATE bylo vydáno ve verzi 1.28. V gitových repozitářích je sice už od února, ale oznámení vydání se na webu objevilo s několikaměsíčním zpožděním (únorové datum zveřejnění je nepravdivé). Jde o první velké vydání od roku 2021. Uživatelsky nejvýznamnější pokrok je v podpoře Waylandu.
select * from relace where typ_predka='P' and predek=42802 select * from polozka where cislo in (42803,42831) order by cislo select * from zaznam where cislo in (57550) order by cislo select soucet from citac where typ like 'P' and cislo=42802
Ctverice zminenych dotazu. Posledni tri by sly celkem snadno aplikovat hromadne na vsechny clanky. Proste by tam tech cisilek trosku pribudlo
Ale ten prvni je v obecnem pripade nejhorsi. Zde ale vim, ze se bude menit jen cislo predka. Jenze stejne radeji hledam obecne reseni. Takze kdyz mam treba dvojice (A,1), (A,2), (B,3), (C,1), IMHO by resenim bylo:
select * from relace where typ_predka='A' and predek in (1,2) select * from relace where typ_predka='B' and predek in (3) select * from relace where typ_predka='C' and predek in (1)
A pak rucne projit vracene radky a podle sloupecku predek rozhazet udaje ke spravnym objektum.
select * from relace where (typ_predka='A' and predek in (1,2)) or (typ_predka='B' and predek in (3)) or (typ_predka='C' and predek in (1))Ale jinak se v tom zatím moc nevyznám Je to tak, že v tabulce polozka je honorář a hlavička diskuze a v zaznam je obsah článku? Šlo by sem ještě dát
create table
pro polozka a zaznam?
Předpokládám, že ta čísla (42803,42831) a (57550) jsou z relace, a které je nebo je polozka a zaznam se pozna podle typ_potomka?
Nestačilo by nepoužívat 'select *
'? Navíc u databází bývá zvykem, že v záznamu nejsou celé BLOBy, ale jen jakési handly na ně, ale nevím, jestli to tak dělá i MySQL.
SELECT * FROM relace AS Rserial, relace AS Rclanky WHERE Rserial.url = ? AND Rserial.cislo = Rclanky.cislo AND Rclanky.typ = 'P' ORDER BY Rclanky.cisloTím bych měl získat čísla všech článků v seriálu. K nim potřebuji přidat obsah (zaznam) a třeba dvě položky z polozka – dejme tomu autor a honorar. Upravím tedy SELECT:
SELECT * FROM relace AS Rserial, relace AS Rclanky, zaznam, polozka AS Pautor, polozka AS Phonorar WHERE Rserial.url = ? AND Rserial.cislo = Rclanky.cislo AND Rclanky.typ = 'P' AND zaznam.cislo = Rclanky.cislo AND Pautor.cislo = Rclanky.cislo AND Phonorar.cislo = Rclanky.cislo ORDER BY Rclanky.cisloStejně by se do SELECTu přidal i počet položek. Na spojování tabulek jsou databáze optimalizované, pokud jsou na příslušných sloupečcích indexy, mělo by to být OK. Výsledkem SELECTu by měl být 1 řádek = 1 článek. Místo
SELECT *
si samozřejmě vyberu jen ty sloupečky, které potřebuji.
Doufám, že tu nepíšu úplné nesmysly a půjde to na strukturu databáze napasovat
SELECT * FROM relace AS Rserial, relace AS Rclanky, zaznam, polozka AS Pautor, polozka AS Phonorar, relace AS Rautor, relace AS Rhonorar WHERE Rserial.url = ? AND Rserial.cislo = Rclanky.cislo AND Rclanky.typ = 'P' AND zaznam.cislo = Rclanky.cislo AND Pautor.cislo = Rautor.cislo AND Rautor.predek = Rclanky.cislo AND Rautor.typ_predka = 'P' AND Phonorar.cislo = Rhonorar.cislo AND Rhonorar.predek = Rclanky.cislo AND Rhonorar.typ_predka = 'P' ORDER BY Rclanky.cislo
CREATE TABLE polozka ( cislo INT AUTO_INCREMENT PRIMARY KEY, -- jednoznacny identifikator typ SMALLINT, -- typ polozky (diskuse, faq, ..) podtyp VARCHAR(30) NULL, -- podtyp data TEXT NOT NULL, -- XML pridal INT(6) NOT NULL, -- odkaz na uzivatele vytvoreno DATETIME, -- cas vytvoreni zmeneno TIMESTAMP NOT NULL -- cas posledni zmeny ); CREATE TABLE zaznam ( cislo INT AUTO_INCREMENT PRIMARY KEY, -- jednoznacny identifikator typ SMALLINT, -- typ zaznamu (HW, SW, clanek ..) podtyp VARCHAR(30) NULL, -- podtyp data LONGTEXT NOT NULL, -- XML pridal INT(6) NOT NULL, -- odkaz na uzivatele vytvoreno DATETIME, -- cas vytvoreni zmeneno TIMESTAMP NOT NULL -- cas posledni zmeny );
ALTER TABLE relace ADD INDEX in_potomek (typ_potomka,potomek); ALTER TABLE relace ADD INDEX in_predek (typ_predka,predek); ALTER TABLE relace ADD INDEX in_predchozi (predchozi); ALTER TABLE relace ADD INDEX in_url (url);
Indexy jsem delal podle EXPLAIN, ale spise jen amatersky.
Pokud jde o prvni dotaz, mas pravdu, take jsem si ted vsimnul, ze ten LIKE je zbytecny, kdyz znam presnou hdonotu. Ale bude to poznat na vykonnosti, kdyz ma sloupecek vzdy jediny znak a ten strcim do vyrazu? Pak snad nebude rozdil mezi porovnanim a LIKE, ne?
Chápu to dobře, že každej jednotlivej příspěvek v diskusi získáváš jedním SQL dotazem? V případě, že ano, nebylo by mnohem efektivnější získat všechny příspěvky z jednoho vlákna pomocí 1 dotazu (například podle UID prvního-kořenového záznamu) a ty pak srávně "pospojovat" podle nějakého identifikátoru udávající pozici ve stromu příspěvků u jednotlivých příspěvků až v aplikaci?
Tiskni Sdílej: