Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 140 (pdf) a HackSpace 77 (pdf).
ESPHome, tj. open source systém umožňující nastavovat zařízení s čipy ESP (i dalšími) pomocí konfiguračních souborů a připojit je do domácí automatizace, například do Home Assistantu, byl vydán ve verzi 2024.4.0.
LF AI & Data Foundation patřící pod Linux Foundation spustila Open Platform for Enterprise AI (OPEA).
Neziskové průmyslové konsorcium Khronos Group vydalo verzi 1.1 specifikace OpenXR (Wikipedie), tj. standardu specifikujícího přístup k platformám a zařízením pro XR, tj. platformám a zařízením pro AR (rozšířenou realitu) a VR (virtuální realitu). Do základu se z rozšíření dostalo XR_EXT_local_floor. Společnost Collabora implementuje novou verzi specifikace do platformy Monado, tj. open source implementace OpenXR.
Byla vydána nová verze 0.38.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 4.4 nebo novější a také libplacebo 6.338.2 nebo novější.
ClamAV (Wikipedie), tj. multiplatformní antivirový engine s otevřeným zdrojovým kódem pro detekci trojských koní, virů, malwaru a dalších škodlivých hrozeb, byl vydán ve verzích 1.3.1, 1.2.3 a 1.0.6. Ve verzi 1.3.1 je mimo jiné řešena bezpečnostní chyba CVE-2024-20380.
Digitální a informační agentura (DIA) oznámila (PDF, X a Facebook), že mobilní aplikace Portál občana je ode dneška oficiálně venku.
#HACKUJBRNO 2024, byly zveřejněny výsledky a výstupy hackathonu města Brna nad otevřenými městskými daty, který se konal 13. a 14. dubna 2024.
Společnost Volla Systeme stojící za telefony Volla spustila na Kickstarteru kampaň na podporu tabletu Volla Tablet s Volla OS nebo Ubuntu Touch.
Společnost Boston Dynamics oznámila, že humanoidní hydraulický robot HD Atlas šel do důchodu (YouTube). Nastupuje nová vylepšená elektrická varianta (YouTube).
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 0 < 9 Ale ja vim, cos chtel rict. Ano, ta metoda neni dokonala a mozna ani dobra. Ale jak jsem rekl hned v prvnim prispevku, v teorii se nevyznam, takze jedine, co jeste muzu, tak zopakovat, co uz jsem rikal:
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: