Byla vydána nová stabilní verze 1.15 (1.15.1147.36) webového prohlížeče Vivaldi (Wikipedie). Z novinek lze zdůraznit možnost nastavení vlastního pozadí okna, přístup k záložkám z hlavního menu, lepší ovládatelnost v režimu celé obrazovky nebo vyřešení problémů se zvukem v HTML5. Nejnovější Vivaldi je postaveno na Chromiu 65.0.3325.183.
Node.js Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 10.0.0 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). Verze 10 se v říjnu stane novou aktivní LTS verzí. Podpora je plánována do dubna 2021.
Neal Cardwell ze společnosti Google oznámil zveřejnění verze 2.0 nástroje pro testování síťového stacku packetdrill. Jde o souhrnné vydání změn z interního vývoje od roku 2013.
Microsoft na svém blogu oznámil, že správce knihoven pro C++ Vcpkg (VC++ Packaging Tool) lze nově používat také na Linuxu a macOS. Aktuálně je pro Linux k dispozici více než 350 knihoven [reddit].
Byly zveřejněny exploity na Nintendo Switch a platformu Tegra X1: Fusée Gelée a ShofEL2. Jejich zneužití nelze zabránit softwarovou aktualizací. Na druhou stranu exploity umožní na Nintendo Switch snadno a rychle nainstalovat Linux, viz. ukázka na YouTube. Jenom je potřeba sáhnout na hardware.
Byla vydána verze 2.12.0 QEMU (Wikipedie). Přispělo 204 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn. Řešeny jsou také bezpečnostní chyby Meltdown a Spectre.
Google zveřejnil seznam 1 264 studentů přijatých do letošního Google Summer of Code. Přehled projektů, studentů, 212 organizací a mentorů je k dispozici na stránkách GSoC.
Oracle vydal verzi 1.0 univerzálního virtuálního stroje GraalVM, který umožňuje běh programů napsaných v jazycích založených na JVM, JavaScript, LLVM bitcode a experimentálně Ruby, R a Python.
Julia Evans pomocí svých kreslených obrázků proniká do Linuxu a informačních technologií. Vedle ucelených zinů publikuje také jednotlivé kreslené obrázky (RSS).
Jordi Sanfeliu vydal verzi 1.0.0 svého unixového jádra Fiwix (Wikipedie) určeného také pro výuku operačních systémů. Dle článku na OSNews na něm začal pracovat již před více než dvaceti lety. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT. Stáhnout a vyzkoušet lze živou disketu nebo CD s GNU/Fiwixem.
zjednodušeně: tabulka atributy (id, typ, nazev, id_hodnota) tabulka hodnota_int (id, hodnota) tabulka hodnota_varchar (id, hodnota) pokud bych to spojil, mohu dostat následující data: +-----------+------------------+--------------------+ | nazev | hodnota_int | hodnota_varchar | +-----------+------------------+--------------------+ | atribut1 | 233 | NULL | | atribut4 | 2332 | NULL | | atribut1 | NULL | textova | +-----------+------------------+--------------------+Je jasné, že pokud budu chtít řadit podle atributu atribut1, tak mám smůlu, protože je jednou typu int a jednou varchar. Řešení je ukládat si do tabulky atributy váhy jednotlivých hodnot řazení (přidat nový sloupec sort). Už jsem to v jednom schématu viděl, otázka je, jak tu hodnotu počítat? Není nějaký normalizovaný postup, pokud budu řadit najednou varchar, datetime, int a decimal?
Ahoj
V teorii databazi se moc nevyznam, ale kdyz muze atribut byt jednou cislo a jindy retezec, tak je IMHO nekde neco spatne.
A pokud ne, tak co neco takoveho:
case atributy.typ when int then convert(varchar...) when datetime then convert (varchar...) . . .Teda jestli to mysql umi
Dejv
case ... convert
ukladat do toho sloupce. A razeni budes mit podle retezce. Taky to neni zrovna ukazka rychlosti, ale asi rychlejsi, nez convert
bude třeba 096 větší než 94Nebude
kdyz muze atribut byt jednou cislo a jindy retezec, tak je IMHO nekde neco spatne
ale neznam detaily a predpokladam, ze vis, co delas
+-----------+------------------+--------------------+ | nazev | hodnota_int | hodnota_varchar | +-----------+------------------+--------------------+ | atribut1 | 233 | NULL | | atribut4 | 2332 | NULL | | atribut1 | NULL | textova | +-----------+------------------+--------------------+ nebo +-----------+------------------+ | nazev | hodnota_int | +-----------+------------------+ | atribut1 | 233 | | atribut4 | 2332 | +-----------+------------------+ a +-----------+--------------------+ | nazev | hodnota_varchar | +-----------+--------------------+ | atribut1 | textova | +-----------+--------------------+ které potom při dotazu spojuji?Pokud budu chtít použít nějaké vícenásobné where condition, tak stejně budu muset spojovat tabulku "samu do sebe", ale u řídké mi odpadne spojování na další vrstvě. Mě osobně připadá výhodnější ta řídká tabulka, ale zaráží mě, že jsem takové řešení u žádného EAV modelu neviděl. Nebo se ta data získávají přes UNION těch tabulek (tzn. mám pak sloupec s kombinací datových typů)?
Vyhledávání v datech bude mnohem rychlejšíPro řídké tabulky bych si tím nebyl tak jistý. Tam bych volil spíš sloupec s XML.
Tiskni
Sdílej: