Red Hat řeší bezpečnostní incident, při kterém došlo k neoprávněnému přístupu do GitLab instance používané jejich konzultačním týmem.
Immich byl vydán v první stabilní verzi 2.0.0 (YouTube). Jedná se o alternativu k výchozím aplikacím od Googlu a Applu pro správu fotografií a videí umožňující vlastní hosting serveru Immich. K vyzkoušení je demo. Immich je součástí balíčků open source aplikací FUTO. Zdrojové kódy jsou k dispozici na GitHubu pod licencí AGPL-3.0.
Český telekomunikační úřad vydal zprávy o vývoji cen a trhu elektronických komunikací se zaměřením na rok 2024. Jaká jsou hlavní zjištění? V roce 2024 bylo v ČR v rámci služeb přístupu k internetu v pevném místě přeneseno v průměru téměř 366 GB dat na jednu aktivní přípojku měsíčně – celkově jich tak uživateli bylo přeneseno přes 18 EB (Exabyte). Nejvyužívanějším způsobem přístupu k internetu v pevném místě zůstal v roce 2024 bezdrátový
… více »Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-10-01. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Jedná o první verzi postavenou na Debianu 13 Trixie.
Byla vydána nová verze 4.6 svobodného notačního programu MuseScore Studio (Wikipedie). Představení novinek v oznámení v diskusním fóru a také na YouTube.
Společnost DuckDuckGo stojící za stejnojmenným vyhledávačem věnovala 1,1 milionu dolarů (stejně jako loni) na podporu digitálních práv, online soukromí a lepšího internetového ekosystému. Rozdělila je mezi 29 organizací a projektů. Za 15 let rozdala 8 050 000 dolarů.
Svobodný multiplatformní herní engine Bevy napsaný v Rustu byl vydán ve verzi 0.17. Díky 278 přispěvatelům.
Bylo vydáno openSUSE Leap 16 (cs). Ve výchozím nastavení přichází s vypnutou 32bitovou (ia32) podporou. Uživatelům však poskytuje možnost ji ručně povolit a užívat si tak hraní her ve Steamu, který stále závisí na 32bitových knihovnách. Změnily se požadavky na hardware. Leap 16 nyní vyžaduje jako minimální úroveň architektury procesoru x86-64-v2, což obecně znamená procesory zakoupené v roce 2008 nebo později. Uživatelé se starším hardwarem mohou migrovat na Slowroll nebo Tumbleweed.
Ministerstvo průmyslu a obchodu (MPO) ve spolupráci s Národní rozvojovou investiční (NRI) připravuje nový investiční nástroj zaměřený na podporu špičkových technologií – DeepTech fond. Jeho cílem je posílit inovační ekosystém české ekonomiky, rozvíjet projekty s vysokou přidanou hodnotou, podpořit vznik nových technologických lídrů a postupně zařadit Českou republiku mezi země s nejvyspělejší technologickou základnou.
… více »Radicle byl vydán ve verzi 1.5.0 s kódovým jménem Hibiscus. Jedná se o distribuovanou alternativu k softwarům pro spolupráci jako např. GitLab.
Odkazy
Pri vývoji webových aplikácií je bežnou požiadavkou aby bol obsah viacjazyčný. Tento blog sa zaoberá návrhom modelov pre uloženie viacjazyčných dát a výhodami / nevýhodami jednotlivých návrhov.
Jazyk SQL neposkytuje žiadnu vstavanú podporu pre viacjazyčný obsah. Návrh databázovej schémy pre viacjazyčný obsahu tak zostáva len na databázovom programátorovi.
Na internete je možné nájsť veľké množstvo rôznych databázových schém, ktoré riešia viacjazyčný obsah. Nedá sa všeobecne povedať ktorá schéma je najlepšia. Vždy to závisí od konkrétneho prípadu použitia. V nasledujúcom texte som sa pokúsil zhrnúť výhody a nevýhody jednotlivých prístupov.
V celom blogu budem aplikovať návrh na model článkov. Polia nazov
a obsah
budú prekladané. Zvyšné polia budú rovnaké pre každý jazyk.
Tabuľka jazykov bude vyzerať nasledovne:
id | kod |
---|---|
1 | sk |
2 | cz |
V selectoch budem vyberať slovenskú lokalizáciu. Pre jednoduchosť nebudem používať join s tabuľkou jazykov. Namiesto toho budem priamo ako ID jazyka používať 1.
Pri tomto prístupe nedochádza k zmene schémy a preklady pre všetky jazyky sa ukladajú do tej istej bunky v špeciálnom formáte. Ako príklad si požičiam formát používaný pluginom qTranslate z Wordpressu. Nasledujúci kód reprezentuje český a slovenský preklad slova „Článok“.
<!--:sk-->Článok<!--:--><!--:cz-->Článek<!--:cz-->
Výber objektov je veľmi jednoduchý. Dáta je však potrebné následne spracovať v aplikácii.
SELECT vytvorene, autor, nazov, obsah FROM clanok;
Pri tomto prístupe sa do modelu pridá jediný stĺpec určujúci jazyk. Medzi jazykovými mutáciami nie je žiaden vzťah, takže v jednej jazykovej mutácii môžu byť úplne iné položky než v inej jazykovej mutácii, čo môže byť v niektorých prípadoch výhodné. Pri pridaní, alebo odstránení jazyka nie je potrebná žiadna modifikácia schémy.
Pre výber slovenských objektov stačí pridať podmienku where
.
SELECT vytvorene, autor, nazov, obsah FROM clanok WHERE jazyk = 1;
V tomto modeli bude primárnym (alebo minimálne unikátnym) kľúčom dvojica uuid
a jazyk
. Objekty (články) sú identifikované stĺpcom uuid
. Ten bude rovnaký pre všetky preklady článku.
Výber objektov je identický ako v prípade predchádzajúceho modelu.
uuid
pre objektyDo modelu pridá každý stĺpec toľkokrát, koľko jazykov bude v aplikácii podporovaných. Nepreložené stĺpce zostávajú bez zmeny.
Pre výber položiek v konkrétnom jazyku je potrebné modifikovať samotný dotaz. Jazykové suffixy musia byť preto chránené voči SQL injection.
SELECT vytvorene, autor, nazov_sk AS nazov, obsah_sk AS obsah FROM clanok;
Oproti predchádzajúcim spôsobom sa tu využívajú 2 tabuľky - časť pôvodnej tabuľky neobsahujúca preklady a tabuľka prekladov. Tá môže byť implementovaná buď prekladmi v riadkoch, alebo v stĺpcoch.
Pri výbere sa používa v oboch prípadoch join, čo môže mať vplyv na výkon. Pri použití tabuľky s prekladmi v stĺpcoch sa pri výbere v konkrétnom jazyku zase modifikuje dotaz a je potrebné zabezpečiť ho voči SQL injection.
-- clanok_row SELECT vytvorene, autor, nazov, obsah FROM clanok INNER JOIN clanok_row ON clanok.id = clanok_row.clanok_id AND jazyk = 1; -- clanok_col SELECT vytvorene, autor, nazov_sk AS nazov, obsah_sk AS obsah INNER JOIN clanok_col ON clanok.id = clanok_col.clanok_id;
Na túto otázku neexistuje jednoznačná odpoveď. Ak máme pevne danú schému, ktorú nemôžeme prispôsobiť bude jediným možným spôsobom uloženie všetkých prekladov oddelených rozumne zvoleným oddeľovačom do pôvodných buniek.
V prípade, že máme rôzny obsah v každom jazyku (napr. v každom jazyku budú iné články) bude najvhodnejším riešením model bez vzťahov medzi jazykmi. Ak však budeme chcieť tie isté objekty v rôznych jazykových mutáciách budeme musieť zvoliť inú schému.
Preklady v riadkoch poskytujú vysokú flexibilitu v možnosti zmeny podporovaných jazykov. V prípade článkov sa pri prekladoch bude opakovať autor a dátum. Schému je možné normalizovať rozdelením tabuľky na samostatnú tabuľku prekladov a zvyšný obsah (posledný príklad).
Preklady v stĺpcoch zachovávajú počet riadkov rovnaký ako počet objektov. Schéma je vhodná len v prípade, že sa v budúcnosti nebude manipulovať s podporovanými jazykmi. Pri väčšom počte jazykov a stĺpcov s prekladmi môže byť táto schéma veľmi neprehľadná. Presun prekladov do samostatnej tabuľky slúži len na sprehľadnenie pôvodnej tabuľky.
Tiskni
Sdílej:
Dovolím si o výkone JOIN
u tak trochu nesúhlasiť. Robievam s dosť veľkými databázami a nie len MySQL, ale aj s podstatne výkonnejšou PostgreSQL. Joiny (LEFT
aj INNER
) môžu mať podstatný vplyv na výkon. Nedávno som riešil problém s pomalým selectom (~2s). Po odstránení joinu klesol čas na ~0.01s. Samozrejme indexy boli nastavené správne a join ich používal.
Problémom v mojom prípade bola veľkosť tabuľky (> 100 000 riadkov) a výber 10 prvkov s offsetom 100 000. Pri výbere bez joinu to pre databázu znamená jednoduchý odskok na 100 000 pložku a vrátenie 10 nasledujúcich položiek. Operácia join však môže vrátiť aj viac, alebo menej riadkov než je v prvej tabuľke. Preto musí databáza pri offsete 100 000 skutočne vykonať join na 100 000 riadkoch. Ak samozrejme ide len o výber s malým offsetom bude mať join zanedbateľný vplyv.
So zvyškom príspevku súhlasím, sám dokonca nepoužívam id jazyka.
Pokud jde join přes primární nebo unikátní klíč, tak by s tím neměl být problém.
Práve, že tu problém je pretože ten join sa minimálne v postgresql materializuje. Obísť sa to dá limitom v subselecte. Nedávno som to riešil v jednej django aplikácii. Musel som optimalizáciou zájsť až po RAW query.