Já jsem narážel na pana Vránu a to bylo na mě.

Priorita databáze by neměla být snadnost psaní SQL dotazů, to nikdy a v žádném případě. Pokud to tak vyjde, že jsou snadné SQL dotazy, je to dobře, ale je to jen vítaný side effect. Na Vaše řešení ohledně lokalizace, například na článku na interval.cz jsme Vás nejen já, ale i další člověk upozorňovali, že není moc dobré. Bohužel interval.cz pak smazal všechny staré komentáře (smazal je u všech článků při přestavbě webu), nebo je někam přesunul. Protože stále šíříte své teze o důležitosti hlavně jednoduchých SQL dotazů, přizpůsobujete otmu řešení, já považuji za povinnost upozornit na naprostou zcestnost a špatné výsledky takového přístupu u jakéhokoli databázového projektu. JAKÉHOKOLI. Je to špatný přístup.

Mě by třeba zajímalo, jak řešíte ty plurály, zda opravdu stačí jen 3 formy, a zda existuje nějaký jazyk, kde je třeba to řešit nějak složitěji. Jsem celkem jazykový analfabet a kromě češtiny a angličtiny jsem nic moc jiného nepoznal. Zda to opravdu algoritmicky stačí.

V zásadě je databáze vždy jen formou cache, od toho byla vždy. Každé řešení má něco do sebe - záleží na použití a kontextu. Pro statická řešení (tedy stále stejný počet položek) a malý počet položek je asociativní pole celkem príma. Naproti tomu databázi nedělá problém mít obrovský počet položek, se kterou bude pracovat plus mínus stejně efektivně jako třeba s deseti položkami. Databáze bude mnohem lépe udržovatelnější. Zejména pokud v každé stránce potřebuji jinou podmnožinu překládaných slov, začne být databázové řešení nesmírně efektivní i po stránce aministrace/údržby překladů. A další věc je, že většina stránek do té databáze sahá tak jako tak, takže když se vhodně navrhne databázové uložení, pak překlad není pro databázi téměř žádná práce navíc. Já netvrdím, že databáze a jedině databáze. Jsem také ovlivněn tím, že jsem byl databázový administrátor, který databáze zná. Dokážu si představit, že běžný člověk se snaží najít nedatabázové řešení. Třeba pole/xml/soubor/seznam konstant/šablony/cokoli. Pokud máte stránku řekněme s několika sty překlady, které jsou potřeba a je to neměnná množina, pak není problém nasadit asociativní pole a bude to dobré řešení. Problém databází je, že je třeba trochu znát teorii a rozumět jim, jinak vyjdou dosti pomalá řešení. Bohužel je pravda, že pokud budete dělat db řešení tak, aby tabulky vyšly co nejjednodušší a dobře se Vám s nimi pracovalo a vyšly nejjednodušší dotazy, tak sice katastrofa to nebude, ale výkon db jde většinou snadno akcelerovat ještě o několik řádů výše zejména u rozsáhlých dat. Čím máte větší data, tím budou výhody databáze zřejmější. Obávám se, že tak asi od 1000 položek už sotva obhájíte cokoli proti databázi. Rychlost, snadno přístupu, udržovatelnost i flexibilita změn překladů prostě bude hrát pro databázi.

Základem každého řešení je dobrá architektura programu/skriptu i struktura databáze. Obvykle kvůli překladu neprovedu ani jeden SQL navíc, než bych provedl bez lokalizace. V krajním případě, když není zbytí jeden až dva SQL dotazy navíc v horším případě. Bohužel někteří lidé, jako třeba pan Vrána tu šíří takové věci jako udělat si SQL dotazy tak, aby byly pro programátora co nejjednodušší, a přizpůsobí tomu i strukturu tabulek. Pak není divu, že výkon není takový, jaký by mohl být. Obvykle si navrhnu strukturu aplikace tak, aby databáze mohla načíst všechny potřebné překlady najednou. Nedělá to žádnou práci. Když načítám data z databáze, ve stejném SQL k nim načtu i překlad.

Přesně tak. Není třeba míchat identifikátor a překlad, byť jen naznačený.

Také si myslím, že identifikátor ála gettext není vhodné řešení. Protože často se stává, že tentýž string je třeba přeložit několika různými texty podle kontextu. Po čase jsem proto začal dávat přednost identifikátorům typu REG_NAME, AUTHOR_NAME, apod., který vyjadřují účel, nikoli to, co by se v textu mělo objevit. Odpadne tím spousta problémů. Jinak překlady řeším v databázi, sice ne v sqlite. Ale dobrá databáze s dobře navrženou strukturou je pekelně rychlá, určitě rychlejší, než parsování xml. Překlady držím v jiné tabulce, než základní data, většinou s unique indexem (id_dat, language).

Mě se líbí, jak se vždycky objeví nezvaní mluvčí za lidi a vysvětlují, že lidi jsou nuceni. Tak tedy: Já osobně nejsem nucen používal Windows na desktopu, ale dělám to, protože jsem s nimi spokojenější, než s Linuxem na desktopu (s unixem, tedy s Linuxem a BSD dělám mnoho let, ale na desktopu mi více vyhovují Windows)- Stejně tak mnohem raději používám ICQ, než jabber. Takže pro mě žádné nucení není. A stejně tak je to myslím s většinou lidí. Jenom jedna (minoritní a v populaci málo zastoupená) komunita pořád vyvolává dojem, že snad většina lidí chce to, co ona komunita a staví je nezvaně jako mluvší většiny lidí. Vidím, že se k tomu hodí cokoli, i cizí neštěstí. Jinak doporučuji Google Webmaster Pages, dozvíte se tam opravdu hodně. Je to IMHO nejlepší cesta, kterou se teď můžete vydat.

Uveřejnění jména mi nevadí :-) U insertu je ten problém, že kromě vložení dat dochází i k přeinidexování (tedy aktualizaci příslušných indexů) v databázi. Tudíž pokud máte nad tabulkou jakýkoli index, tak samozřejmě po každém dotazu dojde také k přebudování indexu. Pak samozřejmě je rozdíl v počtu dotazů. Proto velké databáze nabízejí funkci zvanou bulk insert, kde prostě insertujete velké množství dat a databáze skutečně jen přidává data. Nesmírně to zrychluje insert velkého množství dat. U MySQL bych se dá zabránit neustálému přebudovávání indexu po každém insertu příkazem INSERT DELAYED, kdy MySQL čeká a i když posíláte větší množství INSERT DELAYED, ona jej vždy vnitřně vykoná po velkých blocích a přebudovává indexy minimálně. U MySQL bude také obrovský rozdíl mezi InnoDb a MyISAM, a ne vždy ve prospěch InnoDb. Jinak u velkých SQL dotazů typu posílám 100 000 dat v jednom SQL příkazu můžete narazit u MySQL na limit velikosti SQL příkazu, který je standardně nastaven na 1 MB. Vám k tomu chyběl opravdu v testu jen příslovečný kousíček. I proto je nebezpečné vytvářet dlouhé příkazy. Ohledně Firebirdu: To je databáze, která nesmírně špatně snáší paralelní zátěž. Při větším zatížení proto je třeba prasit. Navíc k Firebordu není ani žádná slušná dokumentace, takže nikdo přesně neví, jak jí optimalizovat (snad kromě těch, kteří jí programují).

"kniha o mysql, kde autor je jmenovec to je shoda jmen" Ne, tu jsem napsal já. :-)

Bude to úplně stejně zatěžující, pokud to dobře napíšete, protože to vnitřně dělá naprosto to samé, co ten Váš INSERT INTO… Nicméně nechápu, proč se bojíte více UPDATE příkazů. To, jestli pošlete jeden SQL příkaz, nebo padesát naprosto nic neříká o rychlosti, s jakou to databáze provede. Jinak živím se databázemi už dvacet let, a bývával jsem krizovým člověkem – člověkem, který řešil problémy, když už databáze padala výkonově na ústa, a bylo potřeba z ní ještě vymáčknout něco, případně jakékoli jiné problémy, se kterým si běžní profesionální databázisté nevědí rady. MySQL jsem mimochodem administroval na starém dnes již zaniklém DC hubu CZECHANNEL PRO, kde jsem musel uchodit naráz kolem 10 tisíc uživatelů nad ní. MySQL pracovala opravdu na hraně toho co dokázala. Proč to říkám? Možná proto, abych Vám řekl, zbavte se mýtů ohledně databází a SQL dotazů. A první mýtus je, že jeden SQL dotaz musí být nutně rychlejší, než série SQL dotazů. Nemusí. Parsování SQL dotazu je naprosto zanedbatelně náročné pro databáze oproti jeho zpracování. A ohýbat dotaz typu INSERT pro akce, které má ve skutečnosti dělat UPDATE a pak hlídat, aby to náhodou neudělalo to co má INSERT dělat – to je neskutečná volovina. Řekl bych to ostřeji, ale mám úctu k lidem jako jste Vy, kteří nad věcmi přemýšlejí, a snaží se dělat věci tak, aby to optimálně fungovalo.

Jednoduše pošlu více příkazů UPDATE. A kdybych už chtěl nutně z toho udělat jeden UPDATE, napíšu: UPDATE tabulka SET pole= (CASE WHEN id_uzivatel=1 THEN 100 WHEN id_uzivatel=2 THEN 150 WHEN id_uzivatel=10 THEN 300 END) WHERE id_uzivatel IN(1,2,300) Miloslav Ponkrác

Nechci-li vložit záznam, pouze upravit, používá se odjakživa UPDATE SQL příkaz. K tomu slouží, sloužil a sloužit bude. Po vykonání příkazu UPDATE lze přečíst počet změněných řádků a zjistit, zda vůbec se našel záznam, který bylo možné změnit. Stačí nehledat exotická řešení a použít naprosté databázové základy. Miloslav Ponkrác