Byl vydán Debian 12.10, tj. desátá opravná verze Debianu 12 s kódovým názvem Bookworm. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 12 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
Byla vydána nová verze 4.5 svobodného notačního programu MuseScore (Wikipedie). Představení novinek v oznámení v diskusním fóru a také na YouTube.
Byla vydána nová verze 8.6.0 správce sbírky fotografií digiKam (Wikipedie). Přehled novinek i s náhledy v oficiálním oznámení (NEWS). Nejnovější digiKam je ke stažení také jako balíček ve formátu AppImage. Stačí jej stáhnout, nastavit právo ke spuštění a spustit.
O víkendu probíhá v Praze na Karlově náměstí 13 konference Installfest 2025. Na programu je celá řada zajímavých přednášek a workshopů. Vstup je zdarma. Přednášky lze sledovat i online na YouTube.
Byla vydána nová verze 2.49.0 distribuovaného systému správy verzí Git. Přispělo 89 vývojářů, z toho 24 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání.
Premiér Petr Fiala (ODS) dnes na síti X vyloučil, že by za jeho vlády mohla začít platit vyhláška, podle níž by poskytovatelé internetového připojení měli uchovávat adresy internetových stránek, na které se lidé připojují.
Flock 2025, tj. konference pro přispěvatele a příznivce Fedory, proběhne od 5. do 8. června v Praze.
Zemřel Mark Klein, který dlouhá léta pracoval pro telekomunikační firmu AT&T a proslavil se jako whistleblower, když zveřejnil informace o spolupráci AT&T s agenturou NSA. Cílem spolupráce bylo sledovat veškerou komunikaci občanů za pomocí zařízeních v místnosti 641A. O spolupráci obou subjektů napsal knihu Wiring Up The Big Brother Machine...And Fighting It.
Byla vydána nová verze 16 integrovaného vývojového prostředí (IDE) Qt Creator. Podrobný přehled novinek v changelogu.
Texas Instruments představil nejmenší mikrokontrolér na světě MSPM0C1104. Je o 38 % menší než současné nejmenší mikrokontroléry. Má pouze 1,38 mm².
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
CREATE TABLE big (a integer);
insert into big values (1,2,3,4,5,6,7,8);
insert into big select a + (select max(a) from big) from big ;
insert into big select a + (select max(a) from big) from big ;
insert into big select a + (select max(a) from big) from big ;
insert into big select a + (select max(a) from big) from big ;
insert into big select a + (select max(a) from big) from big ;
insert into big select a + (select max(a) from big) from big ;
insert into big select a + (select max(a) from big) from big ;
insert into big select a + (select max(a) from big) from big ;
insert into big select a + (select max(a) from big) from big ;
insert into big select a + (select max(a) from big) from big ;
DO $$
declare r integer;
declare s integer;
declare t integer;
begin
t=0;
for r in 1..100000 loop
select sum(a) from big where a between (r % 8000) AND (r % 8000) + r % 50 into s;
t=t+s;
end loop;
end;
$$;
CREATE INDEX biga ON big(a) ;
SELECT hrac FROM tabulka_1 WHERE (datumpridania > 1307400000 AND datumpridania < 1307492665) AND team = 'barcelona';mal by som teda nadefinovať index takto:
CREATE INDEX ON tabulka_1 (team, datumpridania)je ten index správne nadefinovaný?
>>pokud je v sloupeci datum, tak bys k němu měl přistupovat jako k datupochopil som, ze tam teda bude lepšie, keď použijem datetime namiesto int, t.j. vo formate 0000-00-00 00:00:00. Je toto potom ok(?):
BETWEEN '2011-01-01' AND '2011-05-30'BETWEEN '2011-01-01 12:54:21' AND '2011-05-30 01:01:05'
BETWEEN '2011-01-01 00:00:00' AND '2011-05-30 23:59:59'alebo
BETWEEN '2011-01-01 00:00:00' AND '2011-05-31 00:00:00'(čo by malo vrátiť približne rovnaké výsledky v oboch prípadoch - avšak asi nevráti zápis s hodnotou 2011-05-30 23:59:59, vráti len tie čo sú menšie) vďaka za pomoc
CREATE INDEX prvy_index ON tabulka_1 (team) CREATE INDEX druhy_index ON tabulka_1 (datumpridania) namiesto CREATE INDEX meno_indexu ON tabulka_1 (team, datumpridania) ?v prípade meno_indexu by sa nejako tie dva stĺpce team+datumpridania previazali? narozdiel od tych prvy_index a druhy_index, kedy sa indexy vytvoria solo pre každý stĺpec? pýtam sa tak blbo, lebo nerozumiem, aký je tam rodiel v tých indexoch :/ ďakujem za trpezlivosť
, že jsem to nepředpokládal, že to musím explicitně vyslovit.
Pokud se "ale pravidelně" používají v systému nějaký dotazy na obě dvě složky indexu (a to zpravidla platí), tak je volba složených indexů ta, která dá největší poměr cena/výkon.
Statistiky to u rozumné databáze nezvoře, protože ty si může bez problémů evidovat po složkách. Jediná nevýhoda je větší velikost indexu, ta je ale furt menší, než dělat složenej a jednoduchej index najednou, popř. zpomalení dané větší velikostí indexu zdaleka není takové jako ztráta času, která by nastala při existenci pouze jednoduchého indexu díky sekvenčnímu zpracování druhé podmínky.
---
PS: V minulym postu jsem to trochu zjednodušil, chytrý databáze (např. postgresql) dokonce uměj kombinovat více indexů: udělaj bitmapovou mapu obou podmínek a pak jí mergnou, ale tadle metoda není zdaleka tak efektivní, jako složený index.
7.6.2011 21:32
moo | skóre: 7
| Praha
Ma to teda zmysel?Nema.
Tohle by se možná dalo označit za jednu z nejčastějších začátečnických chyb. Rozdělením stejných záznamů do několika tabulek docílíte jen toho, že v lepším případě budete místo jednoduchých dotazů tvořit nepřehledné, nesrozumitelné a neoptimalizovatelné konstrukce založené na union dvou dotazů přes jednotlivé tabulky. Tedy ve vašem případě, kdy jsou ty tabulky dvě; pokud jich je víc, obvykle to končí iterováním přes jednotlivé tabulky.
Desetitisíce záznamů v tabulce nejsou ani zdaleka důvodem k panice, natož k podobným šíleným konstrukcím. Databáze jsou stavěné na to, aby efektivně pracovaly s daty, a nemá smysl jim házet klacky pod nohy tím, že ze strachu budete uměle komplikovat strukturu těch dat.
Tiskni
Sdílej:
