Google Chrome 144 byl prohlášen za stabilní. Nejnovější stabilní verze 144.0.7559.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 10 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře (YouTube).
Microsoft zveřejnil zdrojový kód XAML Studia a uvolnil ho pod MIT licencí. XAML Studio je nástroj ze světa Windows, určený pro tvorbu uživatelského rozhraní aplikací pomocí XAML (Extensible Application Markup Language). Stalo se tak zhruba po osmi letech od prvního prohlášení Microsoftu, že se tento kód chystá zveřejnit.
TimeCapsule, 'časová kapsle', je jazykový model trénovaný výhradně na datech z určitých míst a časových období, aby se tak napodobila autentická slovní zásoba, způsob vyjadřování a názory dané doby. Na Hugging face jsou k dispozici modely natrénované na historických textech dostupných v oblasti Londýna mezi lety 1800 až 1875.
Radicle byl vydán ve verzi 1.6.0 s kódovým jménem Amaryllis. Jedná se o distribuovanou alternativu k softwarům pro spolupráci jako např. GitLab.
Zemřel Scott Adams, tvůrce komiksových stripů Dilbert parodujících pracovní prostředí velké firmy.
Sdružení CZ.NIC vydalo novou verzi Knot Resolveru (6.1.0). Jedná se o první vydanou stabilní verzi 6, která je nyní oficiálně preferovanou a doporučovanou verzí, namísto předešlé verze 5. Více o Knot Resolveru 6 je možné se dočíst přímo v dokumentaci.
Byl vydán Linux Mint 22.3 s kódovým jménem Zena. Podrobnosti v přehledu novinek a poznámkách k vydání. Vypíchnout lze, že nástroj Systémová hlášení (System Reports) získal mnoho nových funkcí a byl přejmenován na Informace o systému (System Information). Linux Mint 22.3 bude podporován do roku 2029.
Wine bylo po roce vývoje od vydání verze 10.0 vydáno v nové stabilní verzi 11.0. Přehled novinek na GitLabu. Vypíchnuta je podpora NTSYNC a dokončení architektury WoW64.
Byl vydán Mozilla Firefox 147.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Firefox nově podporuje Freedesktop.org XDG Base Directory Specification. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 147 bude brzy k dispozici také na Flathubu a Snapcraftu.
Asociace repair.org udělila anticeny těm nejhorším produktům představeným na veletrhu CES 2026. Oceněnými jsou například šmírující kamery Amazon Ring AI, chytrý běžecký pás od společnosti Merach, která otevřeně přiznává, že nedokáže zabezpečit osobní data uživatelů, případně jednorázové lízátko, které rozvibrovává čelisti uživatele a tak přehrává hudbu. Absolutním vítězem je lednička od Samsungu, která zobrazuje reklamy a kterou lze otevřít pouze hlasovým příkazem přes cloudovou službu.
TAB1 id | nazev | obec | ico | dic | act ---+-------------+------+--------+----------+------ 15 | AAA s.r.o. | Brno |12345678|CZ12345678| 0 TAB2 uziv | id | akce | datum -----+----+---------+--------- 2 | 15 | smazano | 2011-7-9 TAB3 id |jmeno |prijmeni ----+------+---------- 2 |Jan | Novák požadovaný výsledek by měl vypadat takto nazev |obec |ico |dic |datum | jmeno |prijmeni ------------+-------+---------+-----------+---------+--------+-------- AAA s.r.o. | Brno |12345678 |CZ12345678 |2011-7-9 | Jan | NovákTy tabulky nejsou kompletní jsou větší, ale pro demonstraci to stačí. TAB2 je v podstatě log z TAB1 kam ukládám všechny změny provedené v TAB1. Act znamená jestli je záznam aktivní nebo je smazán(jelikož má vazbu i na jinou tabulku tak není smazán, ale označen jako neaktivní). Výsledná tabulka je seznam všech smazaných záznamů z TAB1 rozšířená o informace kdy byl záznam označen jako smazaný a kdo to udělal. Problém je, že si s tím nevím rady. Udělat to na straně PHP není problém, ale chci to udělat na straně serveru PostgreSQL. Máte někdo nějakou radu?
Řešení dotazu:
SELECT tab1.nazev, tab1.obec, tab1.ico, tab1.dic, tab2.datum, tab3.jmeno, tab3.prijmeni FROM tab1 JOIN tab2 ON (tab1.id = tab2id) JOIN tab3 ON (tab2.uziv = tab3.id) WHERE tab1.act = 0 AND tab2.akce = 'smazano'Případně starým zápisem JOINu (mně připadá přehlednější):
SELECT tab1.nazev, tab1.obec, tab1.ico, tab1.dic, tab2.datum, tab3.jmeno, tab3.prijmeni FROM tab1, tab2, tab3 WHERE tab1.id = tab2id) AND tab2.uziv = tab3.id) AND tab1.act = 0 AND tab2.akce = 'smazano'Také by to chtělo udělat normalizaci, ta akce asi nebude jen tak libovolný text – spíš budete mít omezený počet akcí, takže byste si na to měl udělat číselník a jenom se do něj odkazovat.
uziv | id | akce | datum -----+----+---------+--------- 2 | 15 | smazano | 2011-7-1 -----+----+---------+--------- 3 | 16 | smazano | 2011-7-8 -----+----+---------+--------- 4 | 17 | smazano | 2011-7-9kterou normální formu tahle relace porušuje? opakovaný výskyt hodnoty "smazano" není o nic víc duplicitní oproti jeho nahrazení nějakým intem a snižuje to čitelnost:
uziv | id | akce | datum -----+----+------+--------- 2 | 15 | 3 | 2011-7-1 -----+----+------+--------- 3 | 16 | 3 | 2011-7-8 -----+----+------+--------- 4 | 17 | 3 | 2011-7-9tohle je porušení 3NF:
uziv_jmeno| uziv_prijmeni | id | akce | datum ----------+---------------+----+------+--------- Filip | Jirsák | 15 | fubar| 2011-7-1 ----------+---------------+----+------+--------- Filip | Jirsák | 16 | fubar| 2011-7-8 ----------+---------------+----+------+--------- Chris | Date | 17 | snafu| 2011-7-9 ----------+---------------+----+------+---------
a nedozvěděl sem se kde že sou ty duplicityTo mě taky zajímá. Páně Jirsák se stále arogantně ohání tím, že on jediný ví a chápe, co je relační databáze, ale vysvětlení duplicit zatím nikde.
pokud bych to potřeboval, tak mi nic nebrání ENUM zmigrovat do tabule, věci co nepotřebuju neprogramuju (YAGNI)Proč místo enumu nepoužít tabulku rovnou, když předpokládám, že mi enum stačit nebude? Není to o nic náročnější, než vytvořit enum (ve skutečnosti je to spíš jednodušší).
stejně tak když se ve sloupci opakujou hodnoty z dané množiny, tak to taky není duplicitaKdyž se opakují odkazy, duplicita to není, když se opakují hodnoty z dané množiny, duplicita to je.
blbost, u počítače to může tak akorát žrát víc paměti, lidem se pracuje líp se stringama; muj čas je dražší než procesorovej časU počítače to také může prodlužovat dobu přístupu – hůř se to indexuje, musíte z disku načíst víc dat… Lidem se líp pracuje s texty, pokud mají nějaký význam. Ale identifikátor řádku? Můžete zvolit nějaký syntetický text, ale
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
15.7.2011 12:32
ahWgay9z bude pro člověka mnohem horší, než 93. Nebo zvolíte nějaký významový identifikátor, který bude užitečný do té doby, než se význam daného řádku odliší od významu identifikátoru. Pak budete mít řádek s významem „varování“ pojmenovaný identifikátorem „chyba“, a lidi to bude akorát mást, protože budou mít tendenci tomu bezvýznamovému identifikátoru přikládat význam.
není, hodnota je vždycky hodnota ať už za ní stojí cizí klíč nebo ne;Nesmíte se nechat zmást tím, že vazby mezi tabulkami jsou v relačních databázích z historických důvodů řešeny hodnotami a cizími klíči.
nesyntetický id sou pro člověka lepší pokud je možný je použítPřičemž podle mne množina „kdy je možný je použít“ je prázdná.
Nesmíte se nechat zmást tím, že vazby mezi tabulkami jsou v relačních databázích z historických důvodů řešeny hodnotami a cizími klíči.Fíha, až takový úlet jsem nečekal… a relační logika jako nic, že?
Když se opakují odkazy, duplicita to není, když se opakují hodnoty z dané množiny, duplicita to je.To znamená, že když uložím do tabulky opakovaná URL, tak to duplicita není? Jsou to také odkazy. Odkazy na cizí klíče jsou také hodnotami z dané množiny. Pokud se opakují, _je_ to duplicita. Zní to jako by v tabulce byly povoleny pouze primární a cizí klíče. Navíc všechny číselné.
Můžete zvolit nějaký syntetický text, aleMy se ale nebavíme o syntetickém textu, to by byl skutečně lepší syntetický integer. Bavíme se o čitelném textu, který má vyjadřovací hodnotu. Pokud takový text nemá a nebude mít další atributy, je zbytečné ho cpát do další tabulky a generovat k němu další syntetické klíče.ahWgay9zbude pro člověka mnohem horší, než93.
My se ale nebavíme o syntetickém textu, to by byl skutečně lepší syntetický integer. Bavíme se o čitelném textu, který má vyjadřovací hodnotu. Pokud takový text nemá a nebude mít další atributy, je zbytečné ho cpát do další tabulky a generovat k němu další syntetické klíče.Ono to nelze obecně tvrdit dokonce ani o tom syntetickém textu.
U počítače to také může prodlužovat dobu přístupu – hůř se to indexuje, musíte z disku načíst víc dat…Udělal jsem si takový maličký benchmark, který sice není příliš relevantní, ale nějaké hodnoty jsem z něj dostal. Udělal jsem si tabulku se třemi sloupci typu ENUM, CHAR(15) a FOREIGN KEY. Do ní 2.6 M záznamů. Potom jsem dělal
select count(*) group by klíč; Zapsal jsem ze 3 měření vždy to nejlepší. Výsledky:
ENUM 3391 ms CHAR(15) 4712 ms FOREIGN KEY 8285 msJe patrné, že cizí klíč je nejpomalejší - to jsme všichni čekali. Vítězem se stal ENUM, ale ne o moc, v závěsu mu byl CHAR. Co však bylo horší, s aktivním cizím klíčem se zpomalil insert. Pochopitelně. Neměřil jsem o kolik. Rozdíly jsou však tak malé, že je prakticky zbytečné rozhodovat se, které řešení použít, jen na základě výkonu. Chtěl jsem tím jen vyvrátit tvrzení, že použití číselníku je výhodnější pro výpočet. Nemusí to platit vždy a za všech okolností.
SELECT COUNT(*) … GROUP BY samozřejmě není procházení všech položek a index se při něm uplatní velice dobře. Záleží na typu indexu, ale většinou už tam ten počet bude uložen; a i kdyby nebyl, stačí spočítat ty položky v indexu a není nutné prolézat celou tabulku.
select subselect.pocet, ciselnik.text from (select count(*) as pocet, cislo from tabulka group by cislo) subselect
inner join ciselnik on (subselect.cislo = ciselnik.cislo)
Tak je konečná, nebo se do ní mohou přidávat položky?Ano.
id | action | .... ------------+ 2 | 1 | ------------+ 3 | 2 | ------------+ 4 | 4 |číselník
id | name | ------------+ 1 | delete | ------------+ 2 | insert | ------------+ 4 | update |přičemž když už bych byl nucenej použít extra tabuli (protože ještě nějaký data, případně potřebuju mít ještě slave tabuli závislou na tom číselníku), tak bych to udělal takhle: data:
id | action | .... ------------+ 2 | delete | ------------+ 3 | insert | ------------+ 4 | update |číselník
id |.... --------+ delete | --------+ insert | --------+ update |což splňuje moje nároky na čitelnost princip relačních databází sem IMHO pochopil docela dobře
Ještě k tomu snížení čitelnosti – použití relační databáze vždy snižuje čitelnost, ... Pokud chcete, aby jedna tabulka v relační databázi byla sama sobě čitelná, nepochopil jste princip relačních databází.Principem normalizace je tedy, že z čitelných databázových tabulek děláme nečitelné? To snad ne. Spojování tabulek relační databázi nedělá.
Tímhle způsobem je možné za normalizovanou prohlásit jakoukoli databázovou strukturu.Protože to pan Jirsák zakázal :D. Bohové.
akce. Pokud to interpretujeme tak, že existuje několik různých typů akcí, každý ten typ akce má svůj název a do onoho sloupečku ukládáme právě ten název, pak taková tabulka samozřejmě nesplňuje 2NF, protože název typu akce nezávisí vůbec na ničem z dané tabulky. Atribut akce taky můžeme interpretovat jako volný textový popisek (de facto poznámka) určený jen pro zobrazení uživateli. Pak to normální formu neporušuje, a takovému atributu nastavím nejspíš nějaký typ dlouhého textu a možnost vkládat NULL. Další možná interpretace je, že ten atribut obsahuje nějaký identifikátor typu akce, přičemž ale samotné typy akcí už mne v databázi nezajímají. Pak to také odpovídá minimálně 3NF, ale zase budu pro atribut identifikátor volit nějaký odpovídající databázový typ – nejlépe enum nebo alespoň omezení s výčtem povolených identifikátorů. Z toho je taky vidět, že datové typy se sice neřeší přímo při normalizaci, ale řeší se při ní význam atributů, který pak logicky ovlivňuje datové typy.
Doufám, že teď už to pochopili i ti, kteří si mysleli, že normální formy se dají stanovit bez znalosti významu atributů.
To prave vsichni nepochybne chapou. … Tyto vlastnosti atributu pochopitelne vychazeji ze skutecnosti, ktera se modeluje, to je tak zjevne, ze se snad o tom neni treba zminovat!V této diskusi to většina lidí nechápala, takže bylo potřeba to zmínit.
Problem je v tom, ze ty zrejme za pomoci kristalove koule interpretujes trivialni text "insert" jako nazev jakesi komplexni entity "akce" a navic predpokladas, ze nazev neni jeji PK.Někdo jiný zase pomocí křišťálové koule interpretuje ten text jako poznámku pouze pro zobrazení a někdo jiný také pomocí křišťálové jako identifikátor akce, která je definována mimo databázi. Můžeme se bavit o tom, co je pravděpodobnější. Nicméně tazatel neuměl napsat ani jednoduché spojení tabulek, takže upozornit ho na to, že by se měl zamyslet i nad tímto atributem, rozhodně není na škodu.
neni zadny duvod, proc by nazev akce nemohl byt primarnim klicemDůvodem je menší efektivita indexu nad řetězcem. Ale to není to, o co původně šlo – původně šlo o to, že (podle mne) v té databázi název akce není primárním klíčem, není to ani enum a ani tam není žádné omezení, protože si tazatel moc nepromýšlel, co ta jeho struktura databáze vlastně vyjadřuje. Tedy nemohl udělat ani normalizaci.
Ty tady vnucujes, ze PK musi byt ve "spravnem" modelu cisloNevnucuju. Jenom tvrdím, že když použiju umělý primární klíč, je z důvodu efektivity lepší použít číslo.
Také by to chtělo udělat normalizaci, ta akce asi nebude jen tak libovolný text – spíš budete mít omezený počet akcí, takže byste si na to měl udělat číselník a jenom se do něj odkazovat.kuka naproti tomu napsal, že výroba tý tabule není normalizace, takže doufam že konečně stáhnete ocas a nebudete se tu vydávat za experta
Protože když chcete podle něčeho filtrovat, musíte mít někde seznam přípustných hodnot.Třeba v ENUM nebo CONSTRAINT.
SELECT * FROM dostane programátor data, a pak si je konečně může v aplikaci spojit, vytřídit a seřadit.
id | nazev ---+----------- 15 | AAA s.r.o.s jediným constraintem - primární klíč nad atributem id můžu filtrovat záznamy podle atributu nazev? ano. pokud tam mam milióny záznamů, pořídim nad atributem name index ty kecy o blobu si strčte za klobouk
ty kecy o blobu si strčte za kloboukTo je asi to jediné, co k tomu můžete říci. Jinak by se ukázalo, že takový BLOB splňuje všechny vaše požadavky na normalizovanou databázi. V normálně strukturované databázi se samozřejmě nebudou používat volné texty pro číselníkové hodnoty, podle kterých se navíc má filtrovat. V normálně strukturované databázi se také nebude filtrovat podle názvu, bude se podle něj nanejvýš hledat. A taky se v normálně strukturované databázi nebude vše řešit „vytvořením indexu“, ale nejprve se podle ukládaných dat logicky navrhne struktura tabulek a vazeb. Ale toho si nevšímejte, to jsou mnohem přísnější požadavky, než které vy nazýváte normalizovanou databází.
V normálně strukturované databázi se také nebude filtrovat podle názvu, bude se podle něj nanejvýš hledat.Nějak mi uniká rozdíl mezi hledáním a filtrováním.
Odstranění těch volně psaných textových hodnot je normalizace.Citation needed.
Toho, že může porušovat nějaká doporučení, si obvykle nejvíc užívá ten, kdo nechápe, k čemu jsou dobrá. Expert, který porušuje nějaké dobré doporučení, velice dobře ví, proč to dělá.Každý databázový specialista ví, že po úspěšné normalizaci musí provést i denormalizaci. Jinak ta aplikace bude líná až nepoužitelná. Pokud potřebuji do databáze sypat logy, tak normalizaci dělat nebudu, to dá rozum. Dokonce nebudu dělat ani silná integritní omezení.
Tiskni
Sdílej:
