Český úřad zeměměřický a katastrální zavedl u anonymního nahlížení do katastru nemovitostí novou CAPTCHA ve formě mapové puzzle: nepřihlášení uživatelé musí nově správně otočit devět dlaždic v 3x3 poli tak, aby dohromady daly souvislý obrázek výseče reálné mapy, přičemž na to mají pouze jeden časově omezený pokus. Test je podle uživatelů i odborníků příliš obtížný a na sociálních sítích pochopitelně schytává zaslouženou kritiku a
… více »Byla vydána verze 1.95.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Mozilla prostřednictvím své dceřiné společnosti MZLA Technologies Corporation představila open-source AI klienta Thunderbolt. Primárně je určený pro firemní nasazení.
Firma Cal.com oznámila, že přesouvá svůj produkční kód z otevřeného do uzavřeného repozitáře z důvodu bezpečnostního rizika umělé inteligence, která prý dokáže vyhledávat a zneužívat zranitelnosti rychleji, než by je jejich vývojářský tým stíhal opravovat. Zároveň zveřejnila samostatnou, open-source verzi Cal.diy pod licencí MIT, ovšem bez řady původních funkcí. O tom, zda je toto opatření rozumné, existují pochyby. … více »
Vývojáři KDE na Mastodonu oznámili vydání balíku aplikací KDE Gear 26.04. Přehled novinek i s náhledy a videi v oficiálním oznámení.
Kryptografická knihovna OpenSSL byla vydána v nové verzi 4.0. Přehled změn v souboru CHANGES.md na GitHubu. Odstraněna byla podpora SSLv2 Client Hello a SSLv3. Ve výchozím nastavení byla zakázána podpora odmítnutých eliptických křivek v TLS dle RFC 8422. Přibyla například podpora Encrypted Client Hello (ECH, RFC 9849).
curl up 2026, tj. setkání vývojářů a uživatelů curlu, proběhne opět v Praze. O víkendu 23. a 24. května v Pracovně.
Aplikace pro ověřování věku uživatelů on-line platforem je technicky hotová a brzy bude k dispozici pro občany EU, oznámila dnes předsedkyně Evropské komise Ursula von der Leyenová. Půjde podle ní o bezplatné a snadno použitelné řešení, které pomůže chránit děti před škodlivým a nelegálním obsahem. Aplikace bude podle ní fungovat na jakémkoli zařízení a bude zcela anonymní.
V prosinci 2012 byla z linuxového jádra odstraněna podpora procesorů 386. Včera započalo odstraňování podpory procesorů 486.
IuRe (Iuridicum Remedium) vyhlásila Ceny Velkého bratra za rok 2025. Slídily roku jsou automobilka Volkswagen, Meta a česká Ministerstva vnitra a průmyslu a obchodu. Autorem Výroku Velkého bratra je dánský ministr spravedlnosti zpochybňující právo na šifrovanou komunikaci. Naopak Pozitivní cenu získali studenti Masarykovy univerzity za odpor proti nucení do používaní aplikace ISIC.
Ahoj mam tabulku v ktorej sa nachadza priblizne 1500 zaznamov, dalsie zaznami tam budu pribudat. v tabulke sa nachadza stlpec ktory identifikuje cloveka, je to tabulka prichodov a odchodov z prace. potrebujem z tabulky casto ziskavat najnovsi zaznam konkretneho cloveka. Ktory dotaz by bol vykonostne lepsi, zatial ma napadlo iba toto: SELECT dochadzka_id FROM dochadzka ORDER BY dochadzka_id DESC LIMIT 1
v tabulke dochadzka sa nachadzaju este stlpce: person_id, prichod_timestamp, odchod_timestamp.
Ahoj, nevím, co na tomto dotazu optimalizovat... Jen je potřeba, aby byl nad dochazka_id index resp. primární klíč. A ještě ti tam chybí WHERE podmínka na person_id (tento sloupec by měl mít také index). Tedy v MySQL bych to napsal asi nasledovně a v náročnosti dotazu problém nevidím:
SELECT dochadzka_id FROM dochadzka WHERE person_id = 1 ORDER BY dochadzka_id DESC LIMIT 0,1
To je dost neskutecne sileny "reseni". Mit v aplikaci hardcoded, ze minimalni person_id je 1? A co kdyz nekdo toho prvniho clovicka odmaze z databaze, to se bude delat uprava i v kodu?...
No napadlo ma take riesenie, ze dam do tabulky dochadzka trigger, ktory do tabulky posledna_dochadzka vzdy po inserte noveho zaznamu na konkretnu osobu vlozy posledne toto id, myslite ze to bude vykonostne horsie s tymto trigerom ako ked mam prehladavat takuto kopu zaznamov?
To zalezi na tom, jak se to bude pouzivat - trigger nema zadny vliv na dotazy, zvysuje pouze cenu insertu. Pokud ti to opravdu pripada tak kriticke, tak pri typickem pouziti (caste dotazy, neprilis caste inserty) toto muze byt dobra volba. Pro radove tisice zaznamu si ale myslim, ze rozdil nebude na rozumnem hardwaru (a databzi) pozorovatelny.
Záleží na tom, kolik budete provádět těch insertů a kolik těch dotazů na poslední příchod. Řešení s poznamenáním si id posledního příchodu (nemusí to být trigger, můžete použít i proceduru a insertovat zásadně jen přes ni) zpomalí insert a zrychlí select. Vzhledem k tomu, že z podstaty věci nepůjde pro jednoho člověka o více než jednotky insertů za den, zvýšením náročnosti insertu bych se moc netrápil. Další možností je samozřejmě udělat si na té tabulce index, ale přes to pomocné pole s id posledního příchodu to asi bude jednodušší, pokud nevyužijete řazení starších příchodů.
Ještě technická poznámka: 1500 řádků v tabulce není žádná "takáto kupa záznamov", to je pořád docela malá tabulka.
Pokud potřebuješ ten záznam "často" jak píšeš, příjde mi i přes to, že se může jednat o zpomalení insertu logičtější ukládat si ten poslední příchod jako speciální hodnotu a tu pak nevyhledávat.
Je tu ještě otázka toho, jestli při vysokém vytížení je poslední přidělené ID opravdu posledním záznamem přidaným do tabulky, ale uznávám že při 1500 záznamech a pracovní morálkou čechů není zase tak vysoce pravděpodobném, že by se tento problém vyskytl :D.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
SELECT max(dochadzka_id) FROM dochadzka [WHERE id_person=...]
Ovsem razeni podle id opravdu neni nejlepsi reseni, sekvence zrucuje jedinecnost, nikoli posloupnost. Kdyz db poslape na vice nodech tak ma zpravidla nakesovany id a kazdy node muze aktualne prirazovat id z jineho rozsahu. Proto je spravnejsi se ptat na dobu vlozeni/zmeny zaznamu. Nicmene pri danem navrhu to nebude opet zcela trivialni, protoze prichodem se bude nejspis insertovat a odchodem updatovat a porovnavani budeme muset delat podle dvou sloupcu. Takze by to chtelo budto pridat sloupec modiftime (a s narustajicim poctem zaznamu se sikne i index), nebo prekopat zcela logiku tabulky a ukladat zvlast zaznamy pro prichod a odchod a rozlisit je typem.
SELECT d.id_dochadzka FROM dochadzka d WHERE d.id_person=1 and d.modiftime = (SELECT max(t.modiftime) FROM dochazka t WHERE t.id_person = d.id_person)
Predpokladam, ze tezko v jeden okamzik bude mit clovek vice zaznamu, to by se pak muselo resit nejakou agregacni funkci. V subselectu misto t.id_person = d.id_person muze byt primo cislo, snizuje to cost. Jestli je to nejaka vyspelejsi db, bude mozne vyhnout se subselectu nejakou statistickou nebo agregacni funkci, nicmene jestli je to vyhodnejsi nebo ne asi bude treba vyzkouset.
Reseni s triggerem neni podle me nejlepsi, protoze to zbytecne bude prochazet tabuli a updatovat predchozi zaznam a spomali to dobu insertu -> prodlouzi dobu zamku nad tabulkou
Tiskni
Sdílej:
