abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    dnes 05:11 | Zajímavý článek

    Obrovská poptávka po plynových turbínách zapříčinila, že datová centra začala používat v generátorech dodávajících energii pro provoz AI staré dobré proudové letecké motory, konvertované na plyn. Jejich výhodou je, že jsou menší, lehčí a lépe udržovatelné než jejich průmyslové protějšky. Proto jsou ideální pro dočasné nebo mobilní použití.

    karkar | Komentářů: 0
    včera 19:55 | Nová verze

    Typst byl vydán ve verzi 0.14. Jedná se o rozšiřitelný značkovací jazyk a překladač pro vytváření dokumentů včetně odborných textů s matematickými vzorci, diagramy či bibliografií.

    Ladislav Hagara | Komentářů: 0
    včera 13:33 | Bezpečnostní upozornění

    Specialisté společnosti ESET zaznamenali útočnou kampaň, která cílí na uživatele a uživatelky v Česku a na Slovensku. Útočníci po telefonu zmanipulují oběť ke stažení falešné aplikace údajně od České národní banky (ČNB) nebo Národní banky Slovenska (NBS), přiložení platební karty k telefonu a zadání PINu. Malware poté v reálném čase přenese data z karty útočníkovi, který je bezkontaktně zneužije u bankomatu nebo na platebním terminálu.

    Ladislav Hagara | Komentářů: 7
    včera 13:22 | Upozornění

    V Ubuntu 25.10 byl balíček základních nástrojů gnu-coreutils nahrazen balíčkem rust-coreutils se základními nástroji přepsanými do Rustu. Ukázalo se, že nový "date" znefunkčnil automatickou aktualizaci. Pro obnovu je nutno balíček rust-coreutils manuálně aktualizovat.

    Ladislav Hagara | Komentářů: 4
    včera 04:55 | Komunita

    VST 3 je nově pod licencí MIT. S verzí 3.8.0 proběhlo přelicencování zdrojových kódů z licencí "Proprietary Steinberg VST3 License" a "General Public License (GPL) Version 3". VST (Virtual Studio Technology, Wikipedie) je softwarové rozhraní pro komunikaci mezi hostitelským programem a zásuvnými moduly (pluginy), kde tyto moduly slouží ke generování a úpravě digitálního audio signálu.

    Ladislav Hagara | Komentářů: 1
    včera 03:22 | Nová verze

    Open source 3D herní a simulační engine Open 3D Engine (O3DE) byl vydán v nové verzi 25.10. Podrobný přehled novinek v poznámkách k vydání.

    Ladislav Hagara | Komentářů: 0
    23.10. 20:11 | Komunita

    V Londýně probíhá dvoudenní Ubuntu Summit 25.10. Na programu je řada zajímavých přednášek. Zhlédnout je lze také na YouTube (23. 10. a 24. 10.).

    Ladislav Hagara | Komentářů: 0
    23.10. 13:22 | Nová verze

    Gemini CLI umožňuje používání AI Gemini přímo v terminálu. Vydána byla verze 0.10.0.

    Ladislav Hagara | Komentářů: 0
    23.10. 12:55 | Pozvánky

    Konference OpenAlt 2025 proběhne již příští víkend 1. a 2. listopadu v Brně. Nabídne přibližně 80 přednášek a workshopů rozdělených do 7 tematických tracků. Program se může ještě mírně měnit až do samotné konference, a to s ohledem na opožděné úpravy abstraktů i případné podzimní virózy. Díky partnerům je vstup na konferenci zdarma. Registrace není nutná. Vyplnění formuláře však pomůže s lepším plánováním dalších ročníků konference.

    Ladislav Hagara | Komentářů: 0
    23.10. 05:33 | IT novinky

    Samsung představil headset Galaxy XR se 4K Micro-OLED displeji, procesorem Snapdragon XR2+ Gen 2, 16 GB RAM, 256 GB úložištěm, operačním systémem Android XR a Gemini AI.

    Ladislav Hagara | Komentářů: 2
    Jaké řešení používáte k vývoji / práci?
     (35%)
     (48%)
     (20%)
     (20%)
     (24%)
     (18%)
     (21%)
     (18%)
     (18%)
    Celkem 268 hlasů
     Komentářů: 14, poslední 14.10. 09:04
    Rozcestník

    Viacjazyčné dáta v SQL databáze

    28.9.2012 22:40 | Přečteno: 1210× | Programovanie | poslední úprava: 28.9.2012 22:52

    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.

    Ukážkový príklad

    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.

    Príklad

    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.

    Všetky preklady v jednej bunke

    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;
    Výhody
    • Nie je potrebná modifikácia schémy
    Nevýhody
    • Nutné parsovanie pri výbere
    • Náchylné na „rozbitie“ pri zanedbanom escapovaní
    • Nemožné vyhľadávanie len vo vybranom jazyku

    Jednoduchý model bez vzťahov medzi jazykmi

    Model bez vzťahov medzi jazykmi

    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ýhody
    • Jednoduchý výber
    • Jednoduché vytváranie objektov
    Nevýhody
    • Vhodné len v prípade, že sú objekty v jednotlivých jazykoch nezávislé

    Preklady v riadkoch

    Preklady v riadkoch

    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.

    Výhody
    • Jednoduchý výber
    Nevýhody
    • Stĺpce, ktoré nie sú preložené (autor a čas vytvorenia) sa opakujú
    • Nutnosť zabezpečiť unikátne uuid pre objekty

    Preklady v stĺpcoch

    Preklady v stĺpcoch

    Do 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;
    Výhody
    • Všetky jazyky prítomné v jedinom riadku
    Nevýhody
    • Zmena podporovaných jazykov si vyžaduje zmenu schémy
    • Pri väčšom počte jazykov veľmi neprehľadné
    • Každý riadok obsahuje preklady do všetkých podporovaných jazykov

    Preklady v samostatnej tabuľke

    Preklady v samostatnej tabuľke

    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;
    Výhody
    • Zmena podporovaných jazykov nevyžaduje zmenu schémy hlavnej tabuľky
    • Žiadne opakovanie
    Nevýhody
    • Výber vyžaduje join

    Ktorú schému si vybrať

    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.

           

    Hodnocení: 100 %

            špatnédobré        

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    edois avatar 29.9.2012 00:48 edois
    Rozbalit Rozbalit vše Re: Viacjazyčné dáta v SQL databáze
    Join není nevýhoda, ale esenciální vlastnost relačních databází. Rozhodně není třeba se ho bát, protože i obyčejnější relační databáze jako MySQL na to použijí indexy a berou v potaz i jejich kardinalitu a pokud s tím neděláme naprosto šílené brikule, není většinou potřeba jim do toho kecat (u MySQL se akorát hodí jednou za čas provést ANALYZE TABLE na všechny tabulky s cizími klíči, aby databáze měla tu kardinalitu nastavenou dobře). Samozřejmě mluvím o INNER JOINu, nikoliv o např. LEFT JOINu, tam už samozřejmě vliv na výkon je (a u MySQL mám na mysli InnoDB, MyISAM stejně cizí klíče neumí, což ovšem neznamená, že tam nejdou udělat příslušné "obyčejné" indexy, aby joiny nezdržovaly).

    Další věc je to, že ten, kdo databázi navrhuje, by měl obecně optimalizovat schéma jako takové tak, aby měl rychlé updaty (a inserty a delete) a teprve potom řešit jak to rozumně najoinovat (a jaké mít vytvořené indexy pro WHERE, GROUP BY a ORDER BY), protože většinou bývá úzké hrdlo na straně zápisů (slave mašin můžu mít co hrdlo ráčí, s masterem to bývá horší).

    Takže za mě rozhodně poslední možnost, tj. překlady v oddělené tabulce (joiny nevadí, nemám nikde zbytečně duplicitní data, nenafukují se mi tudíž indexy, při přidání jazyka nemusím dělat alter, který může taky dopadnout tak, že se celá tabulka musí zkopírovat atd.).

    A ještě poradím, že (v případě MySQL) vážně není nutné mít IDčka jazyků jako inty, pokud mám 64bit architekturu (což už je snad dneska jediná rozumná myslitelná varianta), pořád mi vychází líp CHAR(2) pro dvoupísmenné jazykové kódy ('en', 'cs', ...), případně CHAR(5) pro pětipísmenné ('en_US', 'en_GB', 'cs_CZ', ...) nebo dvakrát CHAR(2), kde druhý může být NULL, pro pětipísmenné s defaultem.
    mirec avatar 29.9.2012 07:49 mirec | skóre: 32 | blog: mirecove_dristy | Poprad
    Rozbalit Rozbalit vše Re: Viacjazyčné dáta v SQL databáze

    Dovolím si o výkone JOINu 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.

    LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
    Josef Kufner avatar 29.9.2012 11:04 Josef Kufner | skóre: 70
    Rozbalit Rozbalit vše Re: Viacjazyčné dáta v SQL databáze
    Pokud jde join přes primární nebo unikátní klíč, tak by s tím neměl být problém. A pokud uděláš limit v subselectu a joinuješ potom, tak s tím také problém nebude. Ale pokud potřebuješ joinovanou tabulku do něčeho ve where, máš smůlu.
    Hello world ! Segmentation fault (core dumped)
    mirec avatar 29.9.2012 12:32 mirec | skóre: 32 | blog: mirecove_dristy | Poprad
    Rozbalit Rozbalit vše Re: Viacjazyčné dáta v SQL databáze
    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.

    LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
    29.9.2012 03:29 retroslava | skóre: 9 | blog: TryCatch | Žižkoff
    Rozbalit Rozbalit vše Re: Viacjazyčné dáta v SQL databáze
    Já jsem používal trošku mix z toho co píšeš. Měl jsem dvě tabulky, kde v jedné jsou společné informace a v druhé ostatní kolonky, které je třeba přeložit. Jazyk jsem ukládal jako string (třeba cs nebo sk). A když si uděláš join a zvolíš jazyk, tak ti to vyletí jako jeden řádek zpátky.
    Pozor! Jsem naprostý idiot. Co jsem napsal včera dnes už dávno neplatí. Zavazuji se, že budu diskutovat nezávazně.
    bertone avatar 30.9.2012 11:40 bertone | blog: Bertone | Bratislava
    Rozbalit Rozbalit vše Re: Viacjazyčné dáta v SQL databáze
    Ahoj, v čom robíš diagrami tabuliek?
    bertone avatar 30.9.2012 11:47 bertone | blog: Bertone | Bratislava
    Rozbalit Rozbalit vše Re: Viacjazyčné dáta v SQL databáze
    ach, diagramy...
    mirec avatar 30.9.2012 12:36 mirec | skóre: 32 | blog: mirecove_dristy | Poprad
    Rozbalit Rozbalit vše Re: Viacjazyčné dáta v SQL databáze
    Rád by som povedal niečo rozumné, ale je to jednoducho kreslené v GIMP-e keďže nič z toho, čo som skúšal buď nebolo dosť stabilné alebo sa to nevliezlo do RAM, alebo to malo výstup vyzerajúci ako ASCII v DOS-e. Inak na reálnu prácu používam tabuľu.
    LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
    Josef Kufner avatar 30.9.2012 17:35 Josef Kufner | skóre: 70
    Rozbalit Rozbalit vše Re: Viacjazyčné dáta v SQL databáze
    To už je lepší dia a jeho class diagramy. Btw, co graphviz?
    Hello world ! Segmentation fault (core dumped)
    mirec avatar 30.9.2012 19:45 mirec | skóre: 32 | blog: mirecove_dristy | Poprad
    Rozbalit Rozbalit vše Re: Viacjazyčné dáta v SQL databáze
    Graphviz používam na diagramy tried, ktoré sú určené len pre mňa. Na databázy neviem vykresliť koncové značky vzťahov (hrable a tak). U diagramov tried je to jednoduché - vee, diamond ...
    LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
    Josef Kufner avatar 30.9.2012 20:30 Josef Kufner | skóre: 70
    Rozbalit Rozbalit vše Re: Viacjazyčné dáta v SQL databáze
    crow, teetee, diamond, odiamond, ... 1 544 761 different combinations
    Hello world ! Segmentation fault (core dumped)
    Josef Kufner avatar 30.9.2012 20:32 Josef Kufner | skóre: 70
    Rozbalit Rozbalit vše Re: Viacjazyčné dáta v SQL databáze
    Btw, nechceš udělat zápisek o tom, jak generuješ ty diagramy tříd graphvizem?
    Hello world ! Segmentation fault (core dumped)
    mirec avatar 30.9.2012 21:07 mirec | skóre: 32 | blog: mirecove_dristy | Poprad
    Rozbalit Rozbalit vše Re: Viacjazyčné dáta v SQL databáze
    No ja som si na to dokonca písal vlastný nástroj, ale nedokončil som ho :-(. Inak dobrý nápad blog o graphvize, ale predtým možno niečo napíšem o AVR, a hackovaní TV LG a tak ... jednoducho čo mám čerstvo v pamäti ;-)
    LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
    4.10.2012 10:20 Jiří Lisický | skóre: 31 | blog: JIL_blog | Olomouc
    Rozbalit Rozbalit vše Re: Viacjazyčné dáta v SQL databáze
    Na nějaké jednoduché kreslení sql struktury se dá použít přímo webová aplikace http://code.google.com/p/wwwsqldesigner/. Má tam i live demo: http://ondras.zarovi.cz/sql/demo/?keyword=default
    3.10.2012 15:54 Xerces
    Rozbalit Rozbalit vše Re: Viacjazyčné dáta v SQL databáze
    Já vím, že je to čistě rozlišovací označení, ale proč zrovna my jsme dvojka?
    mirec avatar 3.10.2012 19:59 mirec | skóre: 32 | blog: mirecove_dristy | Poprad
    Rozbalit Rozbalit vše Re: Viacjazyčné dáta v SQL databáze
    Pretože u nás vychádza slnko skôr :-P Ale vážne som slovák, ako prvý ma zvyčajne napadne slovenský jazyk, žiadny hlbší význam tam nie je.
    LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
    Josef Kufner avatar 3.10.2012 20:28 Josef Kufner | skóre: 70
    Rozbalit Rozbalit vše Re: Viacjazyčné dáta v SQL databáze
    To jo... mohl použít CHAR(2) jako primární klíč.
    Hello world ! Segmentation fault (core dumped)
    mirec avatar 3.10.2012 22:30 mirec | skóre: 32 | blog: mirecove_dristy | Poprad
    Rozbalit Rozbalit vše Re: Viacjazyčné dáta v SQL databáze
    Mohol, ale nevyzeral by som teraz ako patriot ;-)
    LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
    11.11.2013 17:08 he
    Rozbalit Rozbalit vše Re: Viacjazyčné dáta v SQL databáze
    LIKE! Som tiež patriot! :-) Ale čechom sme mohli dať 0 .. alebo -1 :-p

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.