Společnost Fairphone stojící za stejnojmennými mobilními telefony představila (pdf) bezdrátová špuntová sluchátka Fairbuds. Opravitelná, s vyměnitelnými bateriemi a tříletou zárukou. Cena 149 eur.
Intel na konferenci Intel Vision 2024 představuje své novinky. Důraz klade na AI. Představil AI akcelerátor Gaudi 3.
Společnost SiFive představila RISC-V vývojovou desku HiFive Premier P550 s SoC Eswin EIC7700 s čtyřjádrovým SiFive Performance P550 Core Complex. Deska bude v prodeji od července letošního roku. SiFive a Canonical spolupracují na podpoře Ubuntu.
Penpot, open source webový nástroj pro designování a prototypování webů a aplikací, který překlenuje propast mezi designéry a vývojáři, byl vydán ve verzi 2.0 (Mastodon, X).
Nejnovějším titulem v Edici CZ.NIC je kniha s názvem Evoluce Pythonu od zkušeného experta v oblasti programování Pavla Tišnovského. Tato novinka přináší ucelený pohled na nejnovější trendy, techniky a knihovny, které se stávají standardem v ekosystému tohoto programovacího jazyka. Autor se zaměřuje na praktické příklady a osvědčené postupy při vývoji softwaru, pokrývající široké spektrum od jednoduchých skriptů až po komplexní webové služby. Publikace je vhodnou volbou pro každého, kdo se zajímá o Python a jeho moderní využití.
Logitech G představil (𝕏) bezdrátovou 60procentní herní klávesnici PRO X 60. Bez kurzorových šipek za 5 289,00 Kč.
Rivendell je open source řešení automatizace rozhlasového vysílání. Zdrojové kódy jsou k dispozici na GitHubu pod licencí GPLv2. Vydána byla verze 4.2.0.
Příspěvek na blogu CZ.NIC informuje, že aukce domén se připravuje ke spuštění a aktuálně dobíhají poslední testy a ladění. Zapojit se lze do veřejného testování.
Uroš Popović experimentuje s Linuxem na Raspberry Pi Zero a dalším levném hardwaru, nejnovější příspěvek se věnuje sestavení a zavádění Linuxu na sotva pětidolarovém SoC Allwinner F1C100S.
Projekt PiVPN, tj. jednoduchý instalátor VPN serveru s podporou WireGuard a OpenVPN na Raspberry Pi, byl s nejnovější verzí 4.6.0 oficiálně ukončen. Projekt zůstane archivován na GitHubu.
Řešení dotazu:
UNIQUE INDEX
bud na (symbol, "datetime")
alebo ("datetime", symbol)
- poradie by som volil podla velkosti time spanu v selecte a tiez variability symbolov v tabulke. EXPLAIN
konkretnej query na konkretnych datach napovie.(smallint primary key, varchar(10) not null)
a previazanie cez cudzi kluc.double precision
by som pouzil numeric.
Vykonanie dotazu by mozno zrychlilo vyclenenie symbolov do inej tabulky, napr. (smallint primary key, varchar(10) not null)
a previazanie cez cudzi kluc
Jak to?
Protože SMALLINT se indexuje lépe, než VARCHAR(10).---
priklady pre pgsql (stale nepozname cielovu DB):Ano, asi se lépe indexuje, ale vyhledávání je pak už stejně rychlé, ne?smallint je fixed-size a ma len 2 bajty (a dovoluje pass-by-value), teda je efektivnejsi pri spracovani a indexovani, jednoducho nema overhead, ktorym "trpi" varlena; smallint je mensi, takze sa zmensi velkost riadku a teda sa ich viac zmesti na stranku, takze sa zmensuje IO;
Čas Symbol 2016-05-24 17:15:59.030 A 2016-05-24 17:15:59.035 A 2016-05-24 17:15:59.123 ATo mohou být tři unikátní záznamy, mohou to být tři „duplicitní“ záznamy, nebo dva duplicitní záznamy a jeden unikátní. Záleží na tom, s jakou přesností čas rozlišujete. Když MP tvrdí, že ta kombinace musí být unikátní, chápu to tak, že to tak je z povahy okolního světa, že ta data prostě takto unikátně vznikají. Pak ale potřebuje vědět, jakou přesnost mají ta reálná data, a stejnou přesnost pak nastavit i v databázi. Také to ale může znamenat, že na vstupu mohou být duplicitní záznamy, a splnění podmínky „musí být unikátní“ se musí zařídit až při vkládání dat do databáze (třeba způsobem, že první nebo poslední vyhrává).
Zatial to nevidim ako "cestu do pekel", ale mozno na peknom pekelnom priklade by to bolo zjavnejsie.Když budete mít na vstupu údaje s přesností na desetinu sekundy, a sloupec bude s přesností na sekundy, můžete na vstupu získat duplicitní údaje. Do databáze je nezapíšete a o data přijdete. Když budete mít na vstupu data s přesností na sekundy a ukládat je budete s přesností na milisekundy, a budete potřebovat třeba 5 minut starý záznam, vezmete aktuální čas, odečtete od něj 5 minut a výsledný údaj budete hledat v databázi. A nenajdete nic, protože hledaná čas bude mít na místě milisekund nejspíš nějaké nenulové číslo, jenže v databázi budou samé nuly.
Když budete mít na vstupu data s přesností na sekundy a ukládat je budete s přesností na milisekundy, a budete potřebovat třeba 5 minut starý záznam, vezmete aktuální čas, odečtete od něj 5 minut a výsledný údaj budete hledat v databázi. A nenajdete nic, protože hledaná čas bude mít na místě milisekund nejspíš nějaké nenulové číslo, jenže v databázi budou samé nuly.
Nebo s tím budu počítat a vezmu poslední záznam před daným časem, poslední záznam po něm nebo interpolaci. Nebo ta tabulka může být jen mezistupněm pro generování kumulovaných dat. Nejde naslepo tvrdit, že něco je špatně, pokud nevíte, k čemu ta data slouží a jak se s nimi pracuje.
timestamp without time zone not null
a u toho komentář, že to musí být unikátní, rovnou se ptám, při jaké přesnosti to má být unikátní. Je možné, že to autor ví, ale pak je vhodné to doplnit i do té definice, čímž se těm otázkám předejde.
Tiskni Sdílej: