Multilanguage – struktura DB

Zdravím. Řeším multilanguage web, a přemýšlím nad strukturou databáze pro výpis článků. Článek nemá předem specifikový počet jazykových mutací, ne všechny články jsou přeloženy. Jako nejvhodnější způsob jsem vymyslel db s 2 tabulkami. První tabulka bude sloužit pro základní info o článku: ID (UNIQUE) Kategorii Viditelnost Autora Druhá tabulka bude obsahovat jazykové mutace: ID mutace (UNIQUE) ID článku ISO název mutace (cs,en,de,...; dle ISO 639-1) Text Název Klíčová slova Popis Perex Přijde mi to jako hezké řešení, při výpisu udělám jednoduchý JOIN. Bohužel, pan Vrána ukazuje jiný způsob (viz. http://php.vrana.cz/ukladani-vicejazycnych-zaznamu.php) a já chci vědět váš názor, co je lepší. Od Vrány mě zaujalo řešení s jednou tabulkou, kde jsou všechny mutace. Takové řešení jsem ještě ve své návrhové fázi zavrhl, ale nyní ho znovu oživuji. Pokud bych tedy použil dané řešení s jednou tabulkou, tak mi vyvstává otázka: Jak prohledávat všechny jazykové mutace, aniž bych musel znát jejich názvy? Jde o to, že když nějaký článek nebude obsahovat danou mutaci (sloupec nebude existovat), tak mě MySQL zabije. Jaký je váš názor na řešení pomocí dvou tabulek, jak jsem popisoval výše? Pro rýpaly, a další individua, která svou neschopnost v běžném životě kompenzují rýpáním na forech: Nekopíruji z cizích webů. Pan Vrána má ovšem hodně kvalitních článků, které ukazují více pohledů na skutečnost, a zrovna v tomto případě mi není jasné, co je lepší. Opět říkám - nekopíruju, pouze hledám možné způsoby řešení, a chci znát způsoby, které používají jiní lidé.

Napsal pr0gr4mm3r;532689

Zdravím.

Řeším multilanguage web, a přemýšlím nad strukturou databáze pro výpis článků.

Článek nemá předem specifikový počet jazykových mutací, ne všechny články jsou přeloženy. Jako nejvhodnější způsob jsem vymyslel db s 2 tabulkami.

První tabulka bude sloužit pro základní info o článku:

ID (UNIQUE)

Kategorii

Viditelnost

Autora

Druhá tabulka bude obsahovat jazykové mutace:

ID mutace (UNIQUE)

ID článku

ISO název mutace (cs,en,de,...; dle ISO 639-1)

Text

Název

Klíčová slova

Popis

Perex

Přijde mi to jako hezké řešení, při výpisu udělám jednoduchý JOIN. Bohužel, pan Vrána ukazuje jiný způsob (viz. http://php.vrana.cz/ukladani-vicejazycnych-zaznamu.php) a já chci vědět váš názor, co je lepší.

Od Vrány mě zaujalo řešení s jednou tabulkou, kde jsou všechny mutace. Takové řešení jsem ještě ve své návrhové fázi zavrhl, ale nyní ho znovu oživuji.

Pokud bych tedy použil dané řešení s jednou tabulkou, tak mi vyvstává otázka: Jak prohledávat všechny jazykové mutace, aniž bych musel znát jejich názvy? Jde o to, že když nějaký článek nebude obsahovat danou mutaci (sloupec nebude existovat), tak mě MySQL zabije.

Jaký je váš názor na řešení pomocí dvou tabulek, jak jsem popisoval výše?

Pro rýpaly, a další individua, která svou neschopnost v běžném životě kompenzují rýpáním na forech: Nekopíruji z cizích webů. Pan Vrána má ovšem hodně kvalitních článků, které ukazují více pohledů na skutečnost, a zrovna v tomto případě mi není jasné, co je lepší. Opět říkám - nekopíruju, pouze hledám možné způsoby řešení, a chci znát způsoby, které používají jiní lidé.

tohle neber jako rypani, jenom fakt: 1. vrana je inteligentni clovek a php zna do puntiku, co se db tyce, tak na tom bude podobne, to ale neznamena, ze ma vzdycky pravdu, pouzivej svou hlavu a vyber reseni, ktere ma pro tebe nejvic plusu - muze to byt to tvoje, muze to byt to jeho, muze to byt i to, ktere tady vubec nepadlo, je jedno, co pouzijes, dulezite je, aby to fungovalo 2. rychlost joinu neni zas tak moc dulezita - jak uz jsem tady parkrat psal - da se totiz velmi efektivne pouzit cache, v tomhle se s vranou proste neshodnu, prijde mi, ze je posedlej rychlosti dotazovani za kazdou cenu 3. kazda struktura db se da predelat - znamena to urcitou praci navic, ale neni to tak, ze jednou neco napises a uz to nejde zmenit - davej si pozor, aby ti premysleni nad problemem nevzalo vic casu nez zvoleni jednoducheho reseni + pripadny pozdejsi prepis - me se to obcas stava :-) 4. pokud mas pevnej pocet jazyku, vubec bych neresil joiny, napral bych to do tabule - cz_title, cz_perex, cz_body, en_title, en_perex, en_body - cili to reseni s jednou tabulkou - teoreticky by to slo i s promennym poctem jazyku, ze bys vzdycky pri pridani provedl alter table, ale v pripade vetsich tabuli by to bylo peklo... 5. tudiz co bych ti doporucil ja - pouzij reseni s jednou tabulkou a az to bude horet, tak to predelej... a nebo pouzij reseni, ktere ti dobudoucna usetri nejvic prace (at uz je to jakekoliv, ktere si myslis), ale tenhle postup ne vzdy funguje (protoze nemame kristalovou kouli a nevime, co budeme potrebovat)

Jasně - toto ani rýpání není. Já mám svoji hlavu, ale vzhledem k tomu, že se v dané oblasti stále rozvíjím, tak mám tendenci své kroky porovnávat s ostatními, a hledat se v tom zlatém středu. Abych ti vysvětlil problematiku mého problému. Dělám si objektové třídy, které mají být co nejuniverzálnější. Tyto třídy budu potom používat k tvorbě webů pro zákazníky Kvůli univerzálnosti vidím v jednotabulkovém řešení problém takový: Jeden článek bude napsán česky a anglicky. Druhý bude anglicky a německy. Potom nebude jednoduché vést si přehled o tom, která jazykové mutace byla vytvořena, nebo je jen prázdná,... Osobně se už od začátku přikláním ke svému dvoutabulkovému řešení, vidím v tom výhody např. při různé kombinaci jazyků u článků. Teď tak uvažuju o smyslu tohoto tématu. Spíš jsem očekával reakci, ve které mi bude ukázán nový pohled na jednotabulkové řešení, ve kterém bude vyřešen problém, který jsem popisoval výše. Děkuji za odpovědi.

Ja sem ti chtel nabidnout hlavne ten pohled, ze vymysleni univerzalnich reseni ti penize nevydela, ty ti vydelaji spokojeni zakaznici... Proč by to měl být problém? pokud není sloupec vyplněn, tak v dané jazykové mutaci článek není přeložen. Ukaž nějakou svou objektovou třídu - trošku mě děsíš - možná se pletu, ale nemáš náhodou v plánu implementovat rich domain model z javy v php? :-)

Problém je např. v dalších funkcích, které nejsou životně důležité, ale jsou vhodné. Např. chci rozlišovat jestli překlad existuje, nebo neexistuje, a na to mi můj způsob přijde vhodnější. A co pokud chci mít v CMS trošku víc přehled? Prostě vytvořím článek, kliknu na přidat překlad, napíšu zkratku jazyku (vyberu ze seznamu), a napíšu článek. Nechci, aby se mi tam místo toho zobrazilo 10 textových polí, a z toho vyplním pouze jedno pro mou jazykovou mutaci. O tom Rich Domain Modelu jsem nesylšel - v Javě jsem nikdy nedělal a v té oblasti se ani zdaleka neorientuju. Javu mám na svém PC nainstalovanou, a běží mi na ní NetBeans, to je vše, co o ní vím. Nechci udělat nějaký multi extra super kolos, který ve své "univerzálnosti" předčí i Wordpress, a bude tudíž 10x pomalejší. Jedná se pouze o třídu s funkcema na přidání, smazání, editaci,... článků. Takových tříd budu mít víc - ankety, fotogalerie, návštěvní kniha. Prostě až zákazník bude chhtít web, tak nebudu dlouhé PHP kódy vkládat do šablony, ale v šabloně prostě na řádku zavolám: $cl = $clanek->zobraz(intval($_GET)); a pak někde jenom echem vypíšu co budu potřebovat ($cl,$cl,...). Toto není žádná ukázka mého kódu. Tady jsem napsal svou iluzi, která doufám v budoucnu bude funkční. Ty skripty tady nechci nijak zveřejňovat. 1)Někdo mi to okopíruje 2)Nemám tak velké sebevědomí - někdo může vytknout můj způsob řešení. Někdo si může všimnout toho, že nejsem bezchybný a vytýkat mi to (a nemám dost času ani na programování, natožpak na nějakou obhajobu své práce před šťouraly kteří nenapsali za celý život ani hallo world). 3)Napiš mi na ICQ, domluvíme se, tobě snad můžu věřit.

nemam v planu te shazovat, ale urcite bys ty veci mohl udelat lepe (pokud volas business logiku v sablone) - a kdyz mi to icq das (treba do PM - v kontaktu jsem ho nenasel), tak ti je rad vyjmenuju a zduvodnim, abys z toho mel i neco vic, nez jenom spatny pocit... jo ... a k tematu - nikdo ti nebrani napsat si do tridy article metodu is_translated_in ( iso_code/language_id ), ktera udela to, co sem rekl - podiva se, jestli obsahuje dalsi radky... a co se tech policek tyce... na to tady mame jquery - javascriptem si vytvoris prepinatko na jednotlive mutace a zobrazi se ti ta, ktera je vybrana... zadny problem neni neresitelny

340-001-012

Já jsem pro udělat dvě tabulky. Připadá mi to programátorsky "správnější" (čistší). Ačkoliv jsem proti psaní kódu, který například vyžaduje větší výkon procesoru nebo sežere víc paměti, tak v tomto případě ji mi úplně fuk, jestli bude join na DB náročnější (nemožnost indexovat apod). U náročnějšího webu se na jedno zobrazení stránky stejně provede řádově několik desítek dotazů, tak tohle mě vážně nevytrhne. Navíc vyhledávání u jednotabulkové verze mi připadá naopak horší. Pokud budu chtít vyhledávat napříč všemi jazyky, tak budu do dotazu cpát všechny sloupce? (text_cz, text_en, text_fr, apod) OT: Připadá mi to podobné, jako kdyby programátor používal jen čistě pole a odmítal by používat objekty (vlastní třídy, dynamické pole, zřetězené seznamy, apod), protože v paměti zabírají více paměti. :-)

Napsal Mazlik;532799

Já jsem pro udělat dvě tabulky. Připadá mi to programátorsky "správnější" (čistší).

Ačkoliv jsem proti psaní kódu, který například vyžaduje větší výkon procesoru nebo sežere víc paměti, tak v tomto případě ji mi úplně fuk, jestli bude join na DB náročnější (nemožnost indexovat apod). U náročnějšího webu se na jedno zobrazení stránky stejně provede řádově několik desítek dotazů, tak tohle mě vážně nevytrhne.

Navíc vyhledávání u jednotabulkové verze mi připadá naopak horší. Pokud budu chtít vyhledávat napříč všemi jazyky, tak budu do dotazu cpát všechny sloupce? (text_cz, text_en, text_fr, apod)

OT:

Připadá mi to podobné, jako kdyby programátor používal jen čistě pole a odmítal by používat objekty (vlastní třídy, dynamické pole, zřetězené seznamy, apod), protože v paměti zabírají více paměti. :-)

ano - a prave proto mame dotazy v repository nejlepe, ze? :-) abysme je nemuseli psat rucne... a repository uz vi, jak dotaz poskladat, aby nam vratila presne ty spravne zaznamy... ad OT: da se ti oponovat - psat tridu a pouivat objekty na hello world je taky picovina... v urcitych pripadech je proste vic tabuli zbytecnost... ale samozrejme nerikam, ze je to nejlepsi reseni, jenom bych to tak pro zacatek udelal...