Dotaz: Řešení jazykových verzí

[Bill Gates]

Ahoj, měl bych dotaz do pléna, zdali někdo nezkoušel, či neměřil výkonnost, ať nevymýšlím kolo. Jde o mysql.

Mějme tabuli translations s cca 20000 záznamy a v ní sloupce text, lang1, lang2, lang3, lang4, lang5, lang6, lang7, vše dejme tomu varchar(200). Index je na sloupci text.

Představme si, že udělám

select lang2 as preklad from translations where text='vyraz_ktery_chci_prelozit'

Vyleze mi sloupec preklad s překladem ze sloupce lang2

Samozřejmě očekává se, že mám jinou tabuli, která definuje který sloupec je která jazyková verze.

Jazykové verze mám tedy jakoby horizontálně ve sloupcích.

----

Pak existuje druhý způsob a to jakoby vertikálně.

Mějme tabuli translations s cca 20000 záznamy krát počet jazykových verzí a v ní sloupce text, langid, translation, vše dejme tomu varchar(200), langid je int(11). Index je na sloupci text & langid i samostatně na text, langid.

Představme si, že udělam

select translation as preklad from translations where text='vyraz_ktery_chci_prelozit' and langid=2

Vyleze mi sloupec preklad s překladem textu v jazykové verzi daného textu kde je langid 2.

Samozřejme očekává se, že mám jinou tabuli, která jazykové verze definuje a její id == translations.langid, je mezi nimi tedy vazba.

---

U toho horizontálního mám omezený počet jazykových verzí daný počtem rezervovaných sloupců, nicméně 7 je pro konkrétní účely naprosto dostatečné se značnou rezervou. Přidat sloupec je trivialní záležitost. U horizontálního také oproti vertikálnímu musím držet i nepřeložené prázdné překlady. Nicméně předpokládá se, že vše bude přeloženo a nic nebude vynecháno, jinak je to považováno za chybový stav a překlady je nutno doplnit.

Jak se komu který způsob jeví? Jaká mohou být úskalí a kde vidíte hlavní problémy toho nebo onoho přístupu?

Předem díky za diskuzi na tohle téma.

---

---

Odpovědi

[EtDirloth]

- ak by som prvy navrh vobec niekedy pouzil, tak len vtedy, ak by som casto selectoval rozne jazykove verzie na jeden riadok (pricom aj toto je mozne obsluzit pri druhom navrhu);

- zrejme zalezi od enginu, ale prvy navrh bude asi zbytocne bloatovat stranky nepouzitymi stlpcami; navyse pridat a odobrat stlpec nemusi byt trivialna zalezitost v runtime;

- ak budes najcastejsie potrebovat preklad prave jednej jazykovej verzie pre dany text, je lepsi druhy navrh;

- neviem ci to je tak aj v mysql, ale malo by platit, ze ak mas (unique) index na (text, langid), tak je plnohodnotnou nahradou za samostatny index na (text); t.j. prvy stlpec. Vseobecne: na stlpce z lava do prava, takze index na (x,y,z) sa pouzije napr. pri WHERE x = 1 aj WHERE x = 1 AND y = 2, nie vsak tak efektivne pri WHERE y = 2 alebo z = 3 (pretoze musi skenovat cely index).

- ak mas max. 7 jazykov, tak na select podla langid bude aj tak lepsi table scan, takze ten index ti asi fakt nebude treba;

[Bill Gates]

Zdravim, diky za prvni nazor. Prave premyslim zdali je lepsi prochazet N x pocet_verzi zaznamu (tedy i v indexu), nebo jen N zaznamu (opet i v indexu). Ono s tou tabuli se bude pracovat prakticky porad a vybirat se budou paralelne ruzne jazykove verze. Typicky co jeden uzivatel, to jeho predvolena jazykova verze. Takze mejme 2 brouzdajici uzivatele, jeden jde porad po lang3 a druhy po lang2. Treba, teoreticky. Ano jasny, ze to neni v ramci jednoho selectu protoze to jsou dva pruchody, ktere o sobe vlastne vubec nevi a jsou to dva oddelene selecty. No a vzhledem k tomu ze to je ta nejctenejsi tabule tak ocekavam ze ona se bude beztak celou dobu drzet v ram. Tudiz toto me prave hloda jestli nakonec oboji neni uplne stejne pouzitelne.

Ja si samozrejme planuju udelat nejake benchmark testy a vysledovat kde co, protoze me to zajima. Osobne casto pouzivam prave to prvni reseni s vice sloupci v jednom radku. Nicmene pouzivam to u projektu kde fakt na nejake zasadni vykonnostni optimalizace se kasle, protoze to jsou projekty kde sem tam prijde uzivatel a jsme i s jednim i s druhym v radu snad maximalne milisekund. No ale pri 200 requestech za sekundu uz mi jde o kazdou milisekundu strojoveho casu.

Tudiz dilema... Tak ci tak :)

Samozrejme v momente kdy bych pridaval sloupec, tak je mi jasne ze se ta tabule musi prepsat. No ale v tomto pripade jsme radove na deseti nebo dvaceti mega dat co se tyce pripadneho prepisu te tabule do nove struktury pri pridani sloupce a to jsme taky maximalne tak na vterine, coz me treba ve 2 rano nejak zasadne taky netrapi.

[Kit]

Tohle je vhodný případ pro NoSQL databázi:

• Gettext
• DB4
• CDB

[dustin]

Třetí variantou je mít tabulku pro každý jazyk. Výhodou je např. možnost stanovit jazyk sloupce, třeba pro řazení či databázový fulltext. Ale to asi stejně neplánuješ využít. Když to provážeš cizími klíči na ID slova, snadno by se to udržovalo. Navíc pokud někdo nebude déle používat některý jazyk, nebyla by jeho tabulka ani v keších (blokových v jádru, v db).

Pro 20 tis. klíčů (tj. tabulka se všemi jazyky do miliónu řádků) bych to tím nekomplikoval a dal vše do jedné tabulky s dvousloupcovým indexem id_slovo + id_language. Případný rozpad můžeš udělat kdykoliv, ale určitě nebude důvod.

[OldFrog {Ondra Nemecek}]

Architektonicky je druhá varianta lepší, protože pro přidání jazyku nemusíš měnit strukturu. Toto hledisko bych upřednostnil a v případě nedostatečného výkonu bych řešit výkon celé aplikace profilováním. Což by pak případně vedlo na přidání nebo úpravy indexů, přidání nějaké cachovací mezivrstvy nebo optimalizaci jednotlivých dotazů.

[Josef Kufner]

Není to lepší architektonicky, ale z pohledu teoretického relačního (normalizovaný tvar databáze a tak vůbec). Z praktického hlediska je to asi nejhorší řešení. Z architektonického hlediska je potřeba mít ve všech případech nad databází vrstvu abstrakce (třeba i jen velmi tenkou), která to přechroupe do srozumitelného a právě teď užitečného tvaru.

[Filip Jirsák]

Je to nejlepší řešení i z praktického hlediska. Mám jediný SELECT, který má dva parametry – hledaný text a jazyk. Kdyby použil tu variantu s více sloupci, musí mít pro každý jazyk speciální SELECT a nějak ho v aplikaci vybírat. A to je jen jednoduchý případ, kdy bude vybírat jen z téhle tabulky. Možná bude chtít tabulku spojovat s další tabulkou – a bude muset SELECTy i pro tento dotaz namnožit podle počtu jazyků.

[Josef Kufner]

To záleží na tom, jak ty selecty vyrábíš. Pokud je máš celé jako string, tak je to nešikovné, ale pokud je dáváš dohromady nějakým (třeba i velmi jednoduchým) query builderem, tak tahle dynamičnost je velmi snadno implementovatelná. Navíc je docela častý požadavek na uživatelské filtrovaní podle různých kritérií, takže takový query builder či podobná abstrakce nad SQL dotazy v té aplikaci stejně bude. Ve výsledku pak parametr s jazykem nepředáš do SQL dotazu, ale do query builderu, takže to vyjde prakticky na stejno.

[OldFrog {Ondra Nemecek}]

Tak k té architektonické výhodě patří obecně i ta neměnnost struktury db, která umožní například přístup do db z jiného systému. Jako možné je oboje ale že bych (zřejmě) začátečníkovi doporučoval dynamicky měnit počet sloupců podle jazyků, to určitě ne. Nevidím v tom jiný důvod než vyšší výkon, který je navíc dost diskutabilní.

[Josef Kufner]

Ono to je i jednodušší. Odpadne jeden join a selecty jsou pak méně komplikované. Takže začátečníkovi bych to naopak doporučil, pokud těch jazyků nemá hodně a nechce je každou chvíli měnit.

[Filip Jirsák]

Jaký JOIN odpadne? SELECTy jsou jednodušší v případě sloupce udávajícího jazyk – podmínka na jazyk se píše normálně do WHERE, jak je každý zvyklý, a ne do SELECT. Doporučovat začátečníkovi ukázkový příklad, jak se to dělat nemá, není dobrý nápad. Porušovat pravidla je rozumné jedině tehdy, když to má nějaký přínos, a hlavně když dotyčný přesně ví, proč ta pravidla porušuje. Což by v tomto případě znamenalo alespoň to, že si umí změřit rozdíl v zátěži databáze, a že mu ten rozdíl něco přinese.

[Josef Kufner]

Tohle je docela obtížná věc. Každé řešení má své nevýhody a hodně záleží na tvojí aplikaci. Docela hodně aplikací to řeší tak, že to prostě neřeší – typicky je pak u jednotlivých položek v databázi uvedeno, v jakém jsou jazyku a tím to končí.

Horizontální řešení se samostatnými sloupci pro překlady má výhodu v tom, že můžeš každému nastavit svoje řazení (MySQL toto má docela propracované). S vertikálním přístupem to neuděláš, takže se při řazení v jiném jazyce nebude dát použít index a bude to pomalé.

Vertikální přístup má také nevýhodu v tom, že indexy jsou větší a tedy i maličko pomalejší. Pokud bys chtěl sdílet překladovou tabulku pro různé vlastnosti, tak ty indexy neuděláš vůbec.

Pak je otázkou, zda přidávat sloupce, nebo tabulky. Rozdělení na tabulky může být výhodné pro kešování, obzvlášť pokud se používá jen jeden z překladů. U malých aplikací je to asi spíš o tom, který druh bordelu ti vadí méně, zda nadbytek sloupečků, či nadbytek tabulek.

Ať to uděláš jakkoliv, určitě to udělej tak, aby se SQL dotazy daly dobře generovat a měl jsi připravené metody pro query builder na přijoinování/výběr toho správného sloupečku. Takový nástroj/abstrakce pak navíc umožní konvertovat z jednoho přístupu na druhý, pokud by se ukázalo, že to byla špatná volba.

[Filip Jirsák]

můžeš každému nastavit svoje řazení

Což má ale význam jedině tehdy, pokud podle té hodnoty opravdu chce řadit.

S vertikálním přístupem to neuděláš

MySQL neumí částečné indexy nebo funkční indexy?

Ať to uděláš jakkoliv, určitě to udělej tak, aby se SQL dotazy daly dobře generovat

Ještě podstatně lepší je udělat to tak, aby se žádné dotazy generovat nemusely. Pak nehrozí, že to generování dotazů bude postižené SQL injection, a databáze může prováděcí plány dotazů kešovat.

[Josef Kufner]

můžeš každému nastavit svoje řazení

Což má ale význam jedině tehdy, pokud podle té hodnoty opravdu chce řadit.

Což je docela časté, neboť do databáze se necpou stringy aplikace, ale data.

MySQL neumí částečné indexy nebo funkční indexy?

Pokud vím, tak ne.

a databáze může prováděcí plány dotazů kešovat.

Kešovat může ve všech případech, jen to občas zabere trochu více místa. Typicky těch jazyků není mnoho, aby to nějak vadilo.

[Filip Jirsák]

Což je docela časté, neboť do databáze se necpou stringy aplikace, ale data.

To, že jsou to data, není podstatné. Řazení podle textu často znamená chybný návrh aplikace. Dává smysl řadit třeba podle data (chronologicky) nebo podle ceny. Řazení podle textu může mít význam, když se dělá nějaký výstup pro tisk (třeba seznam osob), ve kterém se bude hledat offline. Ale řazení podle textu velice často znamená, že aplikace nechává něco hledat člověka očima, místo aby mu nabídla možnost zadat hledaný text. A zrovna u těch jazyků a navíc 20 000 záznamů je velice pravděpodobné, že to nikdo nebude chtít řadit.

[Bill Gates]

Ano. K trideni zde konkretne dochazet podle textu v drtive vetsine pripadu nebude. I kdyz ano bude. V backendu pri serazeni zaznamu samozrejme i vcetne fulltextove filtrace. Ale tam me zasadne vykon az tak nezajima, protoze to neni ta nejmarkantnejsi zatez. Setrizeni i fulltext teto tabule podle textoveho indexu (co chci prekladat) mi dava odezvy do 10ti milisekund. V pripade backendu tohle tedy skutecne neresim a ve frontendu se tridit nebude.

[dustin]

Jaký máš v té mysql fulltext?

[Filip Jirsák]

Důležité je, proč to na tom backendu chcete řadit. A když už to tedy chcete řadit, zda to opravdu je potřeba řadit dle zvyklostí v daném jazyce.

[Kit]

10 ms je už třetina celkové odezvy serveru a má smysl to trochu optimalizovat.

[Bill Gates]

Mam tu nejake zatezove testy. Scriptovani v PHP.

Vytvoril jsem si script, ktery mi data z puvodni vertikalni tabule prelil do horizontalni. Jsou tam totozna data. Meni se jen struktura.

Pak jsem si napsal dalsi script, ktery nejdrive vybere z jedne z tabuli 200 nahodnych rozdilnych indexu a tyto si ulozi bokem do indexovaneho pole. Pak jede jeden po druhem a provadi select do prvni tabule a po dokonceni prvniho testu do druhe tabule. Vybira vzdy nahodnou jazykovou verzi. Vysledky z obou mereni uklada do pole jako jednoduchy string a cele to pole pak ulozi po dokonceni testu do souboru abych se na vysledek mohl podivat.

Vypada to velmi podobne, ale presto horizontalni vychazi o neco rychlejsi - zvladne toho o neco vice.

----- horizontal -----
Space usage: Data 1.5 MiB, Index 144 KiB, Total 1.7 MiB.
$sql="select ".$column." as xtext from horiz_table where text_index='".addslashes($textindex)."'";

----- vertical -----
Space usage: Data 1.5 MiB, Index 896 KiB, Total 2.4 MiB.
$sql="select text as xtext from vert_table where text_index='".addslashes($textindex)."' and langid='".$langid."'";

        horizontal vertical  
test 1    409832    380722
test 2    417419    384763
test 3    410420    387814

Ty pocty jsou pocty radku, ktere se povedlo vybrat do presnych 30s. Cas meren pomoci microtime(true) a odecitano od casu startu ziskaneho stejne tak pomoci microtime, aby nam neutekly nejake ty zlomky sekund. Dokud rozdil je <30, tak makame.

[Bill Gates]

Jeste dodatek: 200 indexu se neustale behem prace rotuje. Pokud se dojde na konec, tak se jedou indexy zase od prvniho. Nahodnost jazykovych verzi je "per select", tedy pokud dojedeme 200 indexu, je pravdepodobne, ze pri dalsim jeti 200 indexu vybirame uplne jine jazykove verze nez v predchozim jeti sekvence 200 indexu. 200 indexu jsem zvolil protoze je pravdepodobne, ze to nebudou indexy skrze celou prekladovou tabulku ale ruzne jazykove verze nad urcitou skupinou prekladovych textu (rekneme tedy onech 200 textu), ktere se aktualne na webu budou vyskytovat a dalsi budou jakoby "skladem" na jiny cas.

[Josef Kufner]

Jak máš udělané indexy? Jen nad text_index nebo text_index + xtext? Mít index nad oběma sloupečky by mohlo být rychlejší, neboť se pak databáze už nemusí dívat do tabulky a má všechna data už z indexu.

[Bill Gates]

Zdravim, je to naznaceho hned v puvodnim dotazu.

index je nad text_index u horizontalniho a u vertikalniho nad text_index a langid a cvicne i na obou dohromady, tedy text_index & langid.

[Kit]

Zkus totéž s DB4 nebo GDBM. Bude to o jeden až dva řády lepší.

V MySQL to má smysl jen tehdy, pokud to bude součástí nějakého JOINu.

[Filip Jirsák]

Určitě byste to měl testovat na dotazech tak, jak budou v aplikaci, protože jinak konstruovaný dotaz může mít jiný prováděcí plán a tedy trvat jinak dlouho. Takže byste měl určitě použít parametrizované dotazy – v tom vašem kódu máte díru SQL injection.

Také jste sice uvedl, jak vypadají tabulky, ale nenapsal jste to nejpodstatnější – jaké jste tam použil indexy.

[Bill Gates]

Zdravim, SQL injection zde v tomto testu skutecne neresim. Tady se jedna o test, nikoliv o produkcni kod.

[Filip Jirsák]

Jak jsem psal, měřit rychlost SQL příkazů na jiných příkazech, než které použijete v produkčním kódu, nedává smysl, protože můžete dostat úplně jiné výsledky.

[Bill Gates]

Zdravim, presne takove sql dotazy budou v aplikaci skutecne velmi casto pouzity s tim ze samozrejme dojde i ke korektnimu osetreni pred sqlinjection, coz vy zde nemuzete poznat zdali osetreno predem je ci neni. Obsah promenne $column, ani $langid z vyse uvedeneho neznate, povazujte tedy jejich obsah z bezp. pohledu za korektni. Berte to tak, ze vse je osetreno a na bezpecnostni aspekty dotaz kladen nebyl. Resim zde vhodnost te ci one struktury pro obecne pouziti.

Maximalne k cemu muze dojit je to ze si pozadovane preklady nakesuju nekam bokem a zeptam se na preklady databazoveho serveru hromadne az na konci v ramci jednoho selectu resiciho preklady. To tu ale prosim take ted neresme. Resime vhodnost horizontalni nebo vertikalni popripade jine (jak tu nekdo psal tabulkove) struktury, tedy konkretniho zpusobu ulozeni jazykovych verzi kdy k nim muzeme pristupovat i zpusobem, ktery vyse popisuju v ramci testu.

Samozrejme pouziti te ci one struktury se muze lisit. Pristup k ni se muze lisit. A to je to k cemu by melo dojit ve zdejsim brainstormingu. Najit vyhody ci nevyhody a daneho zpusobu. Ne vse se hodi na vse.

[Filip Jirsák]

Ošetření před SQL injection jsou parametrizované dotazy. Ty ve vašem testu nemáte, takže buď v testu používáte jiné dotazy, nebo nebudete mít ošetřené SQL injection. To, že to nejsou parametrizované dotazy, tedy že není ošetřeno SQL injection, je vidět na první pohled.

Manipulace s daty (tedy ve vašem případě úprava proměnných $column, $langid a $textindex) není ošetřením SQL injection – je to pouze ošklivý hack, kterým se může a nemusí podařit SQL injection zabránit (většinou se to nepodaří). Ukázkový příklad toho, proč to nefunguje, jste napsal ve svém komentáři – povazujte tedy jejich obsah z bezp. pohledu za korektni. Berte to tak, ze vse je osetreno. Přesně tohle si řekne programátor a neprovede ani ten hack. Proto je lepší pokud je to aspoň trochu možné vyhnout se hackům a SQL injection opravdu „ošetřit“ (ono to ve skutečnosti není žádné ošetření, je to normální použití) a použít parametrizované dotazy.

Pokud řešíte jen vhodnost či nevhodnost struktury uložených dat, řešíte to špatně. Protože náročnost získání nějakých dat ovlivňují tři věci – struktura uložení dat, použité indexy a použité dotazy. Nemá smysl řešit jenom samotnou strukturu dat, protože sebelepší strukturu můžete úplně zabít nevhodnými indexy nebo špatně napsanými dotazy.

[Bill Gates]

Prosím vás, pane Jirsák. $column je ohraničen už v sobě v obsahu zpětnými apostrofy a sloupec $column vzniká sloučením konstanty dané v kódu a čísla, tedy int, tedy například "text_l1". Tady skutečně sql injection nehrozí a pokud ano, tak ukažte (třeba v jiném vlákně na téma bezpečnost SQL dotazů) jakým způsobem si to představujete tenhle vektor útoku. $langid je INT a je i tak ošetřen a přetypován aby byla jistota, že tam celé číslo skutečně bude a nikdy nic jiného, ani float, ani string, ani objekt, ani pole, prostě jen a jen celé číslo. Jak chcete celočíselným číslem udělat SQL injection to fakt nechápu. $textindex je ošetřen také a jsou escapovány znaky, kterými se dá uniknout ze syntaxe. Proboha neřešte věci na které se vás nikdo neptá. Jste chytrej člověk, ale diskuze s vámi je někdy značně složitá. Ze všeho nejhorší je že všechny defaultně považujete za blbce. Kdybych tu měl vypsat výčet všeho na co mě skutečně nemusíte upozorňovat, protože jsem si toho ze své více než 15ti leté programátorské praxe vědom aby jste měl jistotu, že mě mimo téma dotazu není třeba na další okolnosti upozorňovat, tak by původní dotaz úplně zapadnul pod tímto výčtem, jen aby jste pochopil, že se nebavíte s blbcem, ale skoro kolegou. Samozřejme respektuji, že vaše znalosti jsou jistě na maximální úrovni. O tom bez pochyby.

[Filip Jirsák]

Žádná manipulace s obsahem vkládaným do SQL dotazu není ochrana proti SQL injection. To, že je něco předem „ohraničeno apostrofy“ platit může a nemusí, navíc „ohraničení zpětnými apostrofy“ rozhodně není obrana proti SQL injection. To, že teď používáte pro skládání dotazu konstantu danou v kódu, neznamená, že to v budoucnosti nezměníte.

jsou escapovány znaky, kterými se dá uniknout ze syntaxe

To je jen zbožné přání. Parser SQL příkazů používá nějaké kódování znaků, nějakou konfiguraci, může se lišit verzi od verze databázového stroje. Jste si jist, že vaše funkce pro escapování tohle všechno zohledňuje? Escapování znaků není ošetření SQL injection, je to jen hack, který možná zachrání ty nejkřiklavější případy.

Ze všeho nejhorší je že všechny defaultně považujete za blbce. Kdybych tu měl vypsat výčet všeho na co mě skutečně nemusíte upozorňovat, protože jsem si toho ze své více než 15ti leté programátorské praxe vědom aby jste měl jistotu, že mě mimo téma dotazu není třeba na další okolnosti upozorňovat, tak by původní dotaz úplně zapadnul pod tímto výčtem, jen aby jste pochopil, že se nebavíte s blbcem, ale skoro kolegou

Ne, nepovažuji všechny za blbce. O SQL injection jsem vám nenapsal ani čárku do té doby, než jste vy sám nenapsal kód, který je na SQL injection náchylný. Upozorňovat vás na SQL injection zjevně je potřeba, když pořád trváte na tom, že budete používat hacky, které možná proti SQL injection trochu pomáhají ale spíš ne. Máte aspoň nějaký důvod, proč používáte nebezpečné skládání SQL dotazů místo parametrických dotazů?

[EtDirloth]

dynamicke dotazy maju oproti prepared vyhodu v tom, ze planner moze pracovat so statistikami adresne pre dane konstanty

a suhlasim s Billom a jeho vytkou - pokora a menej citovej viazanosti na osvojene axiomy je to, co by zmenilo taketo rady od odbornika z rypania na produktivnu diskusiu

[Filip Jirsák]

Psal jsem to opakovaně, že je potřeba testovat ty samé dotazy, které se pak mají použít. Ad-hoc dotazy se chovají jinak, než parametrizované dotazy – optimalizace pro konkrétní data je jeden příklad, nutnost vždy znovu dotaz parsovat a sestavovat prováděcí plán zase mluví proti ad-hoc dotazům. Ale pro použití ad-hoc dotazů je potřeba mít sakra dobrý důvod, protože tam neustále hrozí SQL injection.

[Bill Gates]

Dobrá pane Jirsák. A jste schopen místo zarytého tvrzení o náchylnosti k sql injection (o coz v tomhle dotazu vubec nejde) zkusit zatezove testy kdy by vam s podobnym objemem dat s parametrickymi dotazy odolnymi vuci sql inection vychazela vertikalni tabule rychleji nez horizontalni, popripade dodat podklady jak jste postupoval, kde mel indexy, atd., alespon ve formatu prinejmensim takovem jako jsem psal ja se svym k sql injection nachylnym testem? Nahazejte tam treba nahodna data, lorem ipsum, je to jedno. Pokud ne a bude vam vychazet na tomtez stroji vertikalni pomalejsi nez horizontalni i tak (stejne jako me), pak se tu bavime uplne o nicem. Diky za provedeny test dle vasi metodiky, tesim se na nej.

[Tomáš]

Zdravím

Ukládat statické texty pro gui do databáze není většinou štastné rozhodnutí. Databáze je primárně na živá (nestatická) data. Stejně jako kód který je statický, neukládáte do databáze, tak i statické texty nedává smysl ukládat do DB.

U statických textů, vás nezajímá transakčnost změn a podobné vlastnosti, které vám poskytují databáze. Zato pravděpodobně budete chtít verzování těchto textů (kdo kdy změnil jaký text) a jednoduchou úpravu v textovém souboru. Pokud při nasazení nové verze vaší aplikace nebudete potřebovat dělat zásah do databáze, tak zredukujete rizika při nasazení (data v databázi nemají příkaz "nainstaluj předchozí verzi před pokaženým nasazením" zatímco u verzovaného aplikačního kódu je to většinou triviální).

Tady máte příklad jak se řeší statické texty.

[Kit]

A co databáze Gettext? Ta je na to přece přímo určena a její verzování nepředstavuje žádný problém.

[Tomáš]

Nevyjádřil jsem se přesně. Coby databáze jsem myslel splňující ACID, což je drtivá většina SQL databází. A na SQL řešení se tazatel ptal.

Gnu gettext je úplně jiný typ úložiště dat a mnohem lépe by IMHO vyhovoval požadavkům tazatele.

[Josef Kufner]

Překlady se netýkají jen textů v GUI. Velmi důležitá jsou i data, například vícejazyčné popisky u produktů. Na GUI je Gettext a jemu podobné nástroje, o tom žádná. Problém je právě s vícejazyčnými daty.