Starší komentáře ke článku: Vícejazyčné webové aplikace a relační databáze
Zpět na článek | Úvodní stránka Interval.cz
Datum vložení: 23.8.2005 9:58:05
Ma byt http://jakarta.apache.org/velocity/; ten co je v clanku je na Velocity GNOME filemanager
Datum vložení: 23.8.2005 9:58:42
Pred nedavnem jsem narazil na trosku jinou datovou strukturu, ktera nebyla nijak tezce priohybana pro potreby vicejazycnosti, jen v ni byla pouzita tabulka glossary, ve ktere byly jako sloupce uvedeny: jazyk pro ktery je dany preklad vytvaren, tabulka pro kterou je dany preklad vytvaren, id radku v tabulce pro ktery je preklad vytvaren, sloupec v dane tabulce ktery se preklada a konecne vlastni preklad daneho sloupce a radku. Vyhodou bych videl to, ze prekladane sloupce maji vzdy nejakou, byt implicitni hodnotu a uvedene schema lze pomerne jednoduse pouzit na jiz vytvorene databazove schema. Pravdou je ze dotazy jsou relativne komplikovane a nelze je tak snadno naklikat v nejakem programku.
Datum vložení: 23.8.2005 10:05:27
Když už bylo zmíněno kódování - jak dostanu řetězec ÀÃÁÂÄÄ z php aplikace do mssql dtb ? Php na W2000 plus IIS.
Datum vložení: 22.11.2005 13:29:01
Kde je problém? IIS s tím moc nesouvisí, PHP asi taky ne. Konektor mssql sice na W2k nejede v unicode, ale to by nemělo vadit. Kouknul jsi co posíláš do DB? Jaké máš kódování na tabulce (zvládá to?) Mě to jede bez problémů, zkus zjistit kde se to kazí...
Datum vložení: 23.8.2005 10:19:27
Dovolil bych si nesouhlasit s tvrzením autora o podpoře jazyků a nastavení národního prostředí v systému MySQL. Ten byl od počátku záměrně projektován jako jazykově nezávislý, což znamená, že sice uživatelům neposkytoval interní nástroje pro práci s jazyky, ale zároveň je v tomto nijak neomezoval, na rozdíl od ostatních systémů. Implementace systému jazyků, znakových sad a národních prostředí v MySQL 4.1 je velmi kvalitní a dalece přesahuje schopnosti průměrných "takyprogramátorů" v PHP. Tito lidé často ani nevědí, co je to znaková sada, natož aby dokázali zvládnout tak mohutný nástroj, jakým je tato databáze vybavena. Z toho pak plyne na webu často citovaný nesmysl o chybách a nedostatcích MySQL...
Datum vložení: 23.8.2005 10:38:47
Vsak v clanku pisi ze verze MySQL 4.1 je jiz solidni ale ma stale sve mouchy. Prace s UTF-8 byla samozrejme mozna jiz predtim, ale byl zde napriklad problem s delkou textovych atributu, jelikoz UTF-8 znaky uklada bud jako 1 nebo 2 Bytove tim padem se text o 100 znacich mohl ulozit v extremnim pripade jako 200 znakovy, nehlede na dalsi velkou neprijemnost a to useknuti retezce v puli 2B znaku. Potom vzikl nedefinovany znak, ktery dokazal pekne zneprijemnit zivot. V clanku jsem jen upozornil, ze s oficialni podporou UTF-8 prislo MySQL opravdu znatelne pozdeji nez napriklat PostgreSQL.
Datum vložení: 23.8.2005 11:05:39
Mohu potvrdit, mel jsem tu cest hledat chybu v jednom redakcnim systemu, ktera byla zapricinena ulozenim znaku s diakritikou v kodovani UTF-8 do 2B. Retezec se pak do sloupecku VARCHAR(xxx) nekdy nevesel cely nebo v nekterych pripadech koncil 'paznakem'.
Datum vložení: 23.8.2005 11:36:35
Nechci být jízlivý, ale řekněte upřímně - byla to snad chyba databáze? ;-)
Datum vložení: 23.8.2005 11:41:59
Samozrejme ze ne, ale pokud by existovala podpora UTF-8 nikdy by k chybe nedoslo.
Datum vložení: 23.8.2005 11:55:55
A samozřejmě by došlo k jiné "chybě z neznalosti". Ale to už jsme, IMO, poněkud OT, věnujme se raději tomu, co je v článku podstatné ;-)
Datum vložení: 1.9.2005 14:35:15
přímá podpora znakových sad s promělivou délkou znaku znamený vždy výrazné zpomalení databázového stroje. jak by jste chtěl řešit např. podporu utf8 na statických MySQL tabulkách? jejich základní výhodou je přeci rychlost (díky přesné adresaci = pevné délce znaků).
Datum vložení: 23.8.2005 17:46:37
UTF-8 může pro znak použít až 4 bajty (bez limitu 6), viz http://interval.cz/clanek.asp?article=2940 + http://en.wikipedia.org/wiki/UTF-8. V takovém případě by 255 znakový VARCHAR vystačil na nějakých 63,75 znaků. Určitým řešením je všechno převádět na UCS-2 (resp. UCS-4) a vždy vytvářet pole s 2x (resp. 4x) větší kapacitou.
Datum vložení: 2.10.2005 20:39:22
Na Postgresu je sice fajn podpora UTF-8, ale.. k pouziti pro vicejazycne aplikace chybi nativni podpora pro locale-per-column. MySQL sice zaspal[aoi], ale kdyz uz dobihali, tak predbehli ;) (bavim se opravdu jen o tomto, podporu dalsich veci do posuzovani nemicham)
Datum vložení: 23.8.2005 14:28:12
Opravdu bylo potřeba napsat celý takovýhle dlouhý článek o tak základní věci, jako je normalizace databáze?
Datum vložení: 23.8.2005 14:36:27
Odpovim velmi jednoduse. Myslim si ze ano. Datova normalizace je sice ve svych zakladech velmi jednoducha, ale presto patri spatne normalizovane databaze stale k nejvetsim problemum mnoha aplikaci.
Datum vložení: 23.8.2005 15:46:14
http://dev.mysql.com/tech-resources/articles/intro-to-normalization.html
Datum vložení: 23.8.2005 17:01:16
Donedávna jsem velmi zásadně zastával názor, že o věcech samozřejmých není třeba psát, ba že by se o nich ani psát nemělo, protože je to jen zbytečný exhibicionismus. V tomto smyslu jsem se mnohokrát vyslovil pod spoty na různých weblozích, které jsem kritizoval za znovuobjevování kola, ohně a proudové stíhačky, zvláště když někteří autoři v průběhu let popisovali opakovaně totéž téma. Po mnoha vzrušených diskusích a trpce nabytých zkušenostech, o něž se dílem postarali mí žáci, dílem příliv nováčků na internetu, jsem svůj názor změnil. I samozřejmosti je nutno opisovat znovu a znovu, protože jinak samozřejmostmi být přestanou. Pokud se nějaká znalost vytrácí z obecného povědomí, je mimořádně důležité ji znovu prezentovat, aby se mohla vrátit na své místo a stát se samozřejmostí spoluzakládající náš pohodlný a bezproblémový život ;-)
Datum vložení: 23.8.2005 21:15:56
Přesně tak. Je to tím, že člověk s postupujícími znalostmi zapomíná na cestu, kterou ušel a zajímá se jen o to, kudy právě kráčí. Přitom jsou tisíce lidí, kteří tu cestu mají teprve před sebou.
Datum vložení: 23.8.2005 21:21:38
A nestačilo by "reinkarnovať" staré a osvedčené články v nejakej rozumnej periodicite? Písať o niečo stále dokola mi ako vývoj k lepšiemu teda nepripadá.
Datum vložení: 24.8.2005 0:50:43
Má poznámka o opakovaném popisování téhož se netýkala Intervalu a už vůbec ne tohoto článku, aby nedošlo k mýlce. Na Intervalu se témata opakují jen tehdy, když se způsob jejich zpracování zcela změní, v závislosti na skokovém vývoji některé technologie. Tehdy je lepší napsat nový článek a nikoli reinkarnovat starý, protože jinak by to bylo matoucí. V ostatních případech - no, jak jsem poznamenal jinde, naše články s časem neztrácejí na čtenosti ;-)
Datum vložení: 24.8.2005 14:12:32
no problém je spíš v tom, že se do programování dere strašná spousta lidí, kterří neprojdou ani tou základní výukou, kde by se naučili strukturovanému přístupu k řešení problému a takovým těm "běžným" věcem jako jsou ověřené/osvědčené algoritmy např. v oblasti třídění či normalizace a důležitost dobře provedeného ER modelu DB...
Datum vložení: 24.8.2005 17:36:46
Jenže ono to není jenom o programování, ono je to i o mnoha jiných věcech...
Datum vložení: 28.8.2005 16:46:39
Súhlasím, hlavne s nástupom vývojových prostredí všetkého druhu sa rozširuje skupina "tiežprogramátorov", pre ktorých je kreatívne programátorske myslenie príliš nevábne a vývoj webových stránok považujú za niečo podobné ako vytvorenie prezentácie v PowerpPinte a pod. ;)
Datum vložení: 14.9.2005 15:36:50
Ano, ovšem spousta lidí tímto může začít a když se chce zlepšovat, tak musí nalézt zdroje. Navíc i opravdový programátor se rád dozví, zdali někdo vyvinul nový, lepší systém nebo čirou náhodou již oběvené "kolo" nezná"
Datum vložení: 29.8.2005 13:06:49
http://php.vrana.cz/ulozeni-jazykovych-verzi.php
Datum vložení: 31.8.2005 20:26:07
Asi se zeptám úplně blbě, ale nejsem programátor - snad mě to omlouvá: Když do databáze (MySQL) ukládám z textového pole webové stránky v UTF-8 a zobrazuji taktéž na stránce v UTF-8, proč mě zajímá v jaké hatmatilce (databáze ukládá asi v ISO) si to databáze zapisuje? Nakonec se to na stránce zobrazí správně i když je obsah databáze "vnitřně" nečitelný.
Datum vložení: 1.9.2005 6:11:58
Viz například http://interval.cz/discussion-read.asp?disc=3993#story39699 ;-)
Datum vložení: 7.10.2005 4:29:05
A to je co? Odkaz sam na seba?
Datum vložení: 7.10.2005 8:02:00
To je odkaz na jiný diskusní příspěvek, kde někdo odpovídá na otázku kladenou v příspěvku, na nějž je příspěvek s tímto odkazem reakcí. Jednodušší by ovšem bylo si kliknout ;-)
Datum vložení: 2.9.2005 9:29:56
ne ze by reseni ktere jste navrhl nebylo super ale ma dost velky problem ;) - treba MSSQL ma limit 256 tabulek na dotaz - coz treba pri mnohonasobnem JOINu a par sub-SELECTech snadno prekrocite a najedno je vase reseni celkem nanic. Navic je vase reseni casove dost narocnejsi protoze pribyva dalsi JOIN coz u velkych systemu muze pri SELECTovani dat z nekolika tabulek znamenat treba i 5 nebo 6 joinu navic coz na vykonu zrovna nepridava. Proto mam mnohem lepsi zkusenosti s pouzitim reseni c.1 - tedy Title_CS, Title_DE, Title_EN a potom dle zvoleneho jazyka generovat potrebnou query (coz samozrejme s trochou prace neni problem kdyz si clovek napise pouzitelnou tridu v PHP nebo jinej jazyku ze ;)) - navic vase reseni je dost nevhodne pro databaze na mensich zarizenych jako je treb SQLCE - tuhle uz tak mizerne pomalou DB byste timhle resenim zabil. takze summary zni - reseni je sice hrozne pekne a obecne a parkrat jsem ho i pouzil ale po zkusenostech se vracim k reseni c.1 ktere me mozna stoji trochu vice diskove kapacity pokud se rozhodnu treba jeden jazyk docasne nepouzivat ale v DB se pro nej budou porad vytvaret zaznamy, ale mam pro zmenu mnohem snadnejsi praci pri vytvareni dotazu a hlavne neplytvam procesorovym casem na joinovani tabulek. samozrejme jeste vetsinou pouzivam oddelenost textu a ostatnich dat do dvou tabulek - tady se totiz pri nepotrebe zrovna uzivat texty extremne zvysuje rychlost dotazu.
Datum vložení: 2.9.2005 11:00:31
Pri spravnem oindexovani je ztrata vykonu minimalni. Neni to zadny slozity join nebo vnejsi join. Je treba se nad temi dotazy zamyslet.
Datum vložení: 4.9.2005 10:16:36
Ok az se zamyslite nad dotazem ktery je delan sumovanim dat asi z padesati tabulek v DB a k tomu se dotahuji texty tak velice rychle zjistite ze ty joiny pro texty jsou sakra otravny a davaji zabrat i Oraclu, nedej boze takove trosce jako je MySQL. Normalizace dat je totiz uzasna vec v idealnim svete, ne ve svete celopodnikovych IS.
Datum vložení: 2.9.2005 13:43:41
"Premature optimization is the root of all evil" Takže jednoznačne súhlasím s normalizovanými tabuľkami v článku a keď sa zistí, že bottleneck sú naozaj joiny a malý počet tabuliek, tak až potom to treba začať riešiť. Až potom môže začať denormalizácia tabuľiek a použitie rendundantných dát je na mieste a úplne v poriadku.
Datum vložení: 29.12.2005 11:57:14
souhlasim s tim ze navrhovane reseni je extreme narocne na system-time u vetsich a navstevovanych webu...z meho pohledu je toto reseni pouzitelne pro male webíky...
Datum vložení: 23.5.2006 18:48:52
Dobrý den, co tohle řešení: Do tabulky, kterou bych chtěl překládat, vložím další atribut preklad_id Pak vytvořím tabulku překladů s atributy: preklad_id jazyk_id fieldname (nazev atributu prekladane tabulky) value (přeložená hodnota) Při dotazu do tabulky, která má atribut preklad_id vezmu jeho hodnotu a vyberu vsechny radky s hodnotou tohoto atributu v tabulce překladů, zbytek potom vyberu z původní tabulky. Myslím, že programově by to nebyl problém vyřešit a výhoda je v tom, že jednoduše kdykoliv přidám další atribut, pro který chci mít překlad.
Datum vložení: 2.3.2007 15:33:12
1. Pokud chci přidat sloupec s překladem, musím nejprve zjistit, jestli už tabulka s překlady existuje nebo ne a podle toho udělat buď ALTER TABLE nebo CREATE TABLE. 2. V každém dotazu je zbytečně navíc právě tolik joinů, z kolika tabulek chci získat překlady. 3. Pokud chci nad překládaným sloupcem vytvořit unikátní klíč, musím zapomenout na to, že přidání jazyka provedu pouhým přidáním řádku do tabulky s jazyky - do všech tabulek je potřeba přidat unikátní klíč pro nový jazyk. Pokud si dotazy pro získávání dat nechci zkomplikovat faktem, že překlad daného jazyka v tabulce nebude, tak je tam při přidání jazyka musím nakopírovat. 4. Pokud nad překlady použiji fulltextové vyhledávání MySQL, smíchají se slova jednotlivých jazyků mezi sebou, takže např. nebude fungovat 50% hranice pro ignorovaná slova. Kromě toho bude vyhledávání pomalé, protože nejde vytvořit složený normální a fulltextový index. V dotazu WHERE jazyk = @jazykID AND MATCH (...) se použije buď normální index nebo fulltextový a všechny nalezené řádky se budou muset projít bez indexu.