DuckDuckGo AI Chat umožňuje "pokecat si" s GPT-3.5 Turbo od OpenAI nebo Claude 1.2 Instant od Anthropic. Bez vytváření účtu. Všechny chaty jsou soukromé. DuckDuckGo je neukládá ani nepoužívá k trénování modelů umělé inteligence.
VASA-1, výzkumný projekt Microsoftu. Na vstupu stačí jediná fotka a zvukový záznam. Na výstupu je dokonalá mluvící nebo zpívající hlava. Prý si technologii nechá jenom pro sebe. Žádné demo, API nebo placená služba. Zatím.
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.
centrální tabulka: uzivatel | kategorie -------------------- jarda | kat. ... tabulka názvů tabulek: tabulka_nazev ------------- soubor1 ... příklad vstupního souboru: uzivatel(string), kvota_limit(int32), certifikat(bin) jarda2, 100, BINARNI_DATA takový soubor se převede do tabulky "nazev_souboru": uzivatel | kvota_limit | certifikat ----------------------------------- jarda2 | 100 | BINARNI_DATA s tím, že se konvertují datové typy (string na varchar, int32 na int, bin na blob) Při výpisu uživatelů pak není problém zobrazit všechny lidi, který mají kvota_limit XY a jsou v kategorii KATEGORIE. Vlastně je to velice rychlé, protože se provede jednoduchá podmínka where na left joinech tabulek.Teď co mám za problém. Ačkoliv je tento návrh rychlý a efektivní, tak se mi vůbec nelíbí zasahovat dynamicky(i když jen občas cca 1x ročně) do struktury db. Proto hledám jiný způsob ukládání dat. Napadlo mě přidat centrální tabulce sloupec a všechno mít v XML struktuře. Jak je na tom třeba mysql či postgresql s hledáním v takové struktuře? Nebo neměli byste lepší nápad na návrh databáze?
uzivatel | kategorie | atributy ------------------------------------ jarda | kat. | XML_STRUKTURATěch řádek je tam teď cca 500 000 v každé spojované tabulce a přibývají další (jsou to takové speciální fiktivní uživatelské účty). V současnosti jsem schopen po spojení 5 takových tabulek vyhledat data (samozřejmě indexovaná) do cca 2 sekund. S manuálním vyhledáváním (pomocí aplikace) v XML by to trvalo déle, proto mě zajímá něco co přímo podporuje databáze, ideální by bylo kdyby zvládla hledat v XML, což ale asi nepůjde? Jakou jinou strukturu bych mohl použít pro ukládání dat, aby hledání bylo stejně rychlé jako doposud?
soubor1 | ------------------------ | | atribut1 atributN | | | hodnota1 hodnota1 hodnota2Takže by to bylo víceúrovňové, uživatel má vždy N vlastností (atributů) a každá vlastnost může mít několik hodnot.
uzivatel | kategorie | atributy ------------------------------------ jarda | kat. | XML_STRUKTURADá se s tím pracovat jak pomocí SQL, tak pomocí XQuery pro XML strukturu. IBM DB2 v9.7 Express-C je na stránkách IBM volně stažitelná a použitelná i pro komerční účely. Jediné omezení jsou tam 2 CPU a 2 GB RAM. Velikost databáze omezená není. Pokud ale vyžaduješ MySQL nebo Postgres, tak: http://wiki.postgresql.org/wiki/XML_Support - taky koukám, že umí XQuery http://dev.mysql.com/tech-resources/articles/xml-in-mysql5.1-6.0.html - tam je to o něco horší
Skupina 1:N Uživatel 1:N Hodnota atributu (Int) N:1 Název atributu 1:N Hodnota atributu (Varchar) N:1 1:N Hodnota atributu (Datetime) N:1 ....Vyhlednávání rychlé, indexované, struktura univerzální, ACID. Je něco, co to neumí? PS: Pokud se něco dělá podle prvního písmene skupiny, je název skupiny zřejmě složený datový typ, takže bych ho rozdělil.
Je něco, co to neumí?Třeba řazení např. pokud budu chtít řadit podle atributu1 vzestupně a zároveň podle atributu2 sestupně (SQL = order by atribut1, atribut2 desc). Také to neumí datové typy (leda že bych měl tolik sloupců kolik existuje datových typů a hodnotu sypal do toho správného).
SELECT * uzivatel u
INNER JOIN atribut a1 ON (u.id = a1.uzivatel_id AND a1.nazev_id = :nazev1)
INNER JOIN atribut a2 ON (u.id = a2.uzivatel_id AND a2.nazev_id = :nazev1)
ORDER BY a1.hodnota, a2.hodnota desc
Jo, nenadefinuješ složený index, ale jednoduchej index atribut(nazev_id, hodnota) to
použije, tak pokud není první řazení podle nějakýho hodně neselektivního kritéria,
tak to je dostatečný.
Na ty nejpoužívanější pak můžeš použít materializovanej view, popř. si nejpoužívanější
vlastnosti sypat rovnou k uživateli. Furt je to rychlejší než cokoli, co dostaneš přes
XPath nebo XQuery.
Různý typy můžeš řešit více tabulkama či více sloupci, těch typů zas tolik není
(int, float, datum, string).
Nechce se mi to řešit aplikačně, lze toto řešit i na databázové úrovni (tak, že pro každý nalezený řádek vypíše z hodnota1-hodnotaN vždy tu, která není NULL)?Hledáš sql funkci
COAELSCE
COALESCE
COALESCE by IMHO bylo zbytečně pomalý - navíc: jak poznáš, podle kterýho typu řadit jako první?
Osobně myslím, že budeš muset někde určit, jakej typ mají daný data. Spoléhat na autodetekci se mi nezdá úplně dobrej nápad. V tu chvíli je podle mě nejlepší nespoléhat na automatiku, ale prostě si udělat konfigurák, kam předepíšeš tendle sloupec je INTEGER, tendle je DATETIME atd.... Sloupce, který v konfiguráku nebudou se pak budou porovnávat jako řetězce.
Výhoda toho je, že pokud budeš potřebovat nějaký spešl řazení, který DB nativně nenabízí, tak se to velmi snadno doimplementuje apod. Jako bonus tam i můžeš snadno implementovat sloupce, který budou přímo v tabulce uživatele a podobný vychytávky. Další výhoda bude jednoduchá "změna typu" danýho sloupce atd...
COALESCE by IMHO bylo zbytečně pomalýPomalejší než index? Určitě. Pomalejší než nějaká hrůza zahrnující xml a fultext? Nevím nevím.
A když to určuje pro zápis, tak proč by to neurčil i pro čtení?To já nevím, já jen odpověděl na dotaz jak najít nenullový sloupec. Ale v původním dotazu nešlo o to jak překopávání schématu přizpůsobit aplikaci, ale jak se strojovému překopávání tabulek vyhnout úplně. Udělat ze sloupců vazbu řádky je IMO celkem dobrý způsob jak to udělat, rozhodně lepší než nějaká hrůznost s xml a fulltextem.
Nastuduj si EAV model, mohlo by to byt to co hledas http://en.wikipedia.org/wiki/Entity-attribute-value_model
Pripadne pokud chces pouzit MySQL + XML http://dev.mysql.com/doc/refman/5.1/en/xml-functions.html
select users.uid, users.name, eav_blob.value, eav_date.value, eav_datetime.value, eav_float.value, eav_int.value, eav_string.value, eav_time.value from users left join eav_blob on (users.uid = eav_blob.uid) left join eav_date on (users.uid = eav_date.uid) left join eav_datetime on (users.uid = eav_datetime.uid) left join eav_float on (users.uid = eav_float.uid) left join eav_int on (users.uid = eav_int.uid) left join eav_string on (users.uid = eav_string.uid) left join eav_time on (users.uid = eav_time.uid) inner join attributes on (attributes.aid = eav_blob.aid OR attributes.aid = eav_date.aid OR attributes.aid = eav_datetime.aid OR attributes.aid = eav_float.aid OR attributes.aid = eav_int.aid OR attributes.aid = eav_string.aid OR attributes.aid = eav_time.aid)zabere celou sekundu a to tam nemám skoro žádná data a zatím jsem ani nepoužíval eav entity.
Tiskni Sdílej: