Jiří Eischmann v příspěvku na svém blogu představuje typy, jak lépe chránit své soukromí na mobilním telefonu: "Asi dnes neexistuje způsob, jak se sledování vyhnout úplně. Minimálně ne způsob, který by byl kompatibilní s tím, jak lidé technologie běžně používají. Soukromí ovšem není binární věc, ale škála. Absolutního soukromí je dnes na Internetu dost dobře nedosažitelné, ale jen posun na škále blíže k němu se počítá. Čím méně dat se o vás posbírá, tím nepřesnější budou vaše profily a tím méně budou zneužitelné proti vám."
Byla vydána nová stabilní verze 25.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Warbler. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Multiplatformní open source spouštěč her Heroic Games Launcher byl vydán v nové stabilní verzi 2.17.0 Franky (Mastodon, 𝕏). Přehled novinek na GitHubu. Instalovat lze také z Flathubu.
Organizace Apache Software Foundation (ASF) vydala verzi 26 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.
Klávesnice IBM Enhanced Keyboard, známá také jako Model M, byla poprvé představena v roce 1985, tzn. před 40 lety, s počítači IBM 7531/7532 Industrial Computer a 3161/3163 ASCII Display Station. Výročí připomíná článek na zevrubném sběratelském webu Admiral Shark's Keyboards. Rozložení kláves IBM Enhanced Keyboard se stalo průmyslovým standardem.
Vyšlo Pharo 13 s vylepšenou podporou HiDPI či objektovým Transcriptem. Pharo je programovací jazyk a vývojové prostředí s řadou pokročilých vlastností.
Java má dnes 30. narozeniny. Veřejnosti byla představena 23. května 1995.
1. července Mozilla vypne službu Fakespot pro detekci podvodných recenzí v internetových obchodech. Mozilla koupila Fakespot v květnu 2023.
8. července Mozilla vypne službu Pocket (Wikipedie) pro ukládání článků z webu na později. Do 8. října si uživatelé mohou vyexportovat data. Mozilla koupila Pocket v únoru 2017. Několik měsíců byl Pocket integrovanou součástí Firefoxu.
Turris OS má aktuálně problém s aktualizací související s ukončením podpory protokolu OCSP u certifikační autority Let's Encrypt.
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
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: