Meta představila prototyp náramku, který snímá elektrickou aktivity svalů (povrchová elektromyografie, EMG) a umožňuje jemnými gesty ruky a prstů ovládat počítač nebo různá zařízení. Získané datové sady emg2qwerty a emg2pose jsou open source.
Byla vydána (𝕏) nová verze 25.7 open source firewallové a routovací platformy OPNsense (Wikipedie). Jedná se o fork pfSense postavený na FreeBSD. Kódový název OPNsense 25.7 je Visionary Viper. Přehled novinek v příspěvku na fóru.
Před 40 lety, 23. července 1985, společnost Commodore představila první počítač Amiga. Jednalo se o počítač "Amiga od Commodore", jenž byl později pojmenován Amiga 1000. Mělo se jednat o přímou konkurenci počítače Apple Macintosh uvedeného na trh v lednu 1984.
T‑Mobile USA ve spolupráci se Starlinkem spustil službu T-Satellite. Uživatelé služby mohou v odlehlých oblastech bez mobilního signálu aktuálně využívat satelitní síť s více než 650 satelity pro posílání a příjem zpráv, sdílení polohy, posílání zpráv na 911 a příjem upozornění, posílání obrázků a krátkých hlasových zpráv pomocí aplikace Zprávy Google. V plánu jsou také satelitní data.
Společnost Proxmox Server Solutions stojící za virtualizační platformou Proxmox Virtual Environment věnovala 10 000 eur nadaci The Perl and Raku Foundation (TPRF).
Byla vydána nová verze 2.4.65 svobodného multiplatformního webového serveru Apache (httpd). Řešena je bezpečnostní chyba CVE-2025-54090.
Společnost Proton AG stojící za Proton Mailem a dalšími službami přidala do svého portfolia AI asistenta Lumo.
Amazon koupil společnost Bee zaměřenou na nositelnou osobní AI aktuálně nabízející náramek Pioneer (YouTube) s mikrofony zaznamenávající vše kolem [𝕏, LinkedIn].
Společnost Teufel nedávno představila svůj první open source Bluetooth reproduktor MYND.
Byla vydána verze 4.2 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Využíván je Free Pascal Compiler (FPC) 3.2.2.
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: