[es] - Organizacija višejezičkih sadržaja

Guardian OfThe Blind
Beograd

Član broj: 1048
Poruke: 78
..shall-bg.customer.sbb.co.yu.

Profil

^{13.04.2006. u 13:00 - pre 219 meseci}

Interesuje me vaše mišljenje i (pogotovo) iskustvo u organizaciji (istih) podataka na više jezika. Prvenstveno me zanima upotreba u CMS-ovima za web-sajtove. Samo da istaknem da ne govorimo ovde o višejezičkom interfejsu, koji je više puta pominjan na PHP i drugim forumima i reklativno se jednostavno implemntira, nego baš o "dinamičkim" podacima iz baze.

Na pamet mi pada nekoliko rešenja:

1. dodavanje novih tabela - svaka tabela koja ima podatke na više jezika se pravi ponovo

Code:

tabela strane_sr
Id  Brojac Naslov Sadrzaj
1   321    Ime    Neki tekst

tabela strane_en
Id Brojac Naslov Sadrzaj
1  321    Name   Some text

Ovde ima nekoliko problema: promena strukture jedne tabele zahteva promenu strukture i ostalih, promena jezički nezavisnih polja u jednoj zahteva promenu u ostalim. Zatim, ukoliko želimo da postavimo linkove (recimo da link mora da sadrži i naslov strane a ne samo Id koji imamo) ka svim ostalim prevedenim kopijama jedne strane (što je čest zahtev), potrebno je više ili jedan komplikovan upit ili posebna struktura koja čuva takve informacije. Ukoliko je potrebna (možda ne tako često) pretraga po podacima na svim jezicima, biće veoma spora. Podaci zauzimaju puno mesta i imaju svoje indekse što nas dovodi i do očigledne prednosti a to je brzina u radu sa konkretnim jezikom koji ne ometa/usporava postojanje ostalih.

2. dodavanje novih redova - u svakoj tabeli koja ima podatke na više jezika, svaki red postoji onoliko puta koliko jezika ima

Code:

tabela strane
Id    Jezik    Brojac    Naslov    Sadrzaj
1    sr        321        Ime        Neki tekst
1    en        321        Name        Some text

Pretpostavljam da je ovo rešenje u startu sporije od prethodnog ali je pitanje koliko? Primarni ključ bi se proširio za polje Jezik ali bi mogao da se doda i poseban indeks po tom polju koji bi ubrzao rad sa samo jednim jezikom. S druge strane linkovi ka prevedenim stranama se lakše nalaze, smao se pri upitu specificira samo Id i dohvate se i ostali (prevedeni) redovi - višak podataka postoji ali je jedan upit brži od dva, zar ne?

3. dodavanje novih kolona - svaka kolona koja sadrži jezički zavisne podatke se ponavalja onoliko puta koliko jezika ima

Code:

tabela strane
Id Brojac Naslov_sr Sadrzaj_sr Naslov_en Sadrzaj_en
1 321 Ime Neki tekst Name Some text

Svi podaci su u istom redu i administriranje (menjanje) sadržaja je najjednostavnije; doduše, slično kao i u prethodnom. Međutim, tabela je sada mnogo "šira" i samim tim verovatno mnogo sporija. Takođe, ovo je strukturno najčudnije rešenje i možda najnelogičnije...

4. hibridno rešenje - deljenje unutar sadržaja

Code:

tabela strane
Id Brojac Naslov Sadrzaj
1 321 Ime||Name Neki tekst||Some text

Ovde je ideja da sadržaje samo onih polja koja sadrže podatke na više jezika interno podelimo nakim separatorima (dao sam samo primer sa || koji ne definiše koji jezik sledi, ali shvatate poentu). Ako želimo pretragu po svim jezicima ovo je najbrže rešenje ali prilično usporava rad sa samo jednim jezikom.

U principu, svaki pristup može da ima primenu u nekim situacijama i za neke tipova podataka, tako da bi valjalo istaći kada je koji najbolje koristiti...

_{[Ovu poruku je menjao Guardian OfThe Blind dana 18.04.2006. u 13:50 GMT+1]}

Odgovor na temu

jablan

Član broj: 8286
Poruke: 4541

+711 Profil

Re: Organizacija višejezičkih sadržaja

^{13.04.2006. u 13:32 - pre 219 meseci}

2, uvek.

BTW, pojam replikacija označava nešto drugo u DB terminologiji...

_{[Ovu poruku je menjao jablan dana 13.04.2006. u 14:39 GMT+1]}

Odgovor na temu

broker

Član broj: 2415
Poruke: 8514
212.62.59.*

+11 Profil

Re: Organizacija višejezičkih sadržaja

^{13.04.2006. u 16:27 - pre 219 meseci}

2 je jedini ispavan nacin.

3 je ok ako je potreba takva da ima konacan broj jezika u bazi (dosta je prakticnije za rad). Ako postoji i najmanja mogucnost da ce se broj jezika menjati, onda opet mora 2

Odgovor na temu

Zidar
Canada

Član broj: 15387
Poruke: 3085
*.eqao.com.

+79 Profil

Re: Organizacija višejezičkih sadržaja

^{13.04.2006. u 16:41 - pre 219 meseci}

2 i samo 2.

3 samo naoko izgleda jednostavnije i prakticnije. Jednostavnije, jer kad otvoris tabelu, vidis odmah original i sve prevode.
Ali, ako hoces
srpsku stranicu, onda treba SELECT naslov_SR FROM myTable
za englesku starnicu, treba SELECT naslov_EN FROM myTable
za nemacku stranicu treba SELECT naslov_GER FROM myTable

Znaci, koliko jezika, toliko i kverija, jer pozovaju razlicite kolone.

Ako je opcija 2. u pitanju, onda imas

SELECT naslov, sadrzaj FROM myTable
WHERE jezik=@ZadatiJezik

Znaci, jedan kveri, uvek iste kolone, samo se manja parametar => stored procedure ili function, ali opet jedna te ista, nezavisno od jezika.

Odgovor na temu

broker

Član broj: 2415
Poruke: 8514
212.62.59.*

+11 Profil

Re: Organizacija višejezičkih sadržaja

^{13.04.2006. u 16:46 - pre 219 meseci}

SQL upit se obicno formira uskriptu takoda je najmanji problem promeniti ime polja zavisno od trenutno izabranog jezika. Uz to, lako je omoguciti da se odjednom napravi edit na oba jezika. Ume da bude mnogo prakticno.

Odgovor na temu

jablan

Član broj: 8286
Poruke: 4541

+711 Profil

Re: Organizacija višejezičkih sadržaja

^{14.04.2006. u 08:43 - pre 219 meseci}

Citat:

broker: SQL upit se obicno formira uskriptu

Bogami kako gde. U firmi u kojoj radim sve je u stored procedurama. Mislim da optimizator upita ne obožava preterano kad mu se kveriji non-stop dinamički generišu.

Odgovor na temu

Zidar
Canada

Član broj: 15387
Poruke: 3085
*.qc.sympatico.ca.

+79 Profil

Re: Organizacija višejezičkih sadržaja

^{17.04.2006. u 15:50 - pre 219 meseci}

Slazem se da je ponekad prakticno drzati polja sa prevodima u jednoj tabeli, ali samo ponekad, u veoma ogranicenom broju vrlo prostih slucajeva.

Gde ja radim, koristimo samo dva jezika, engleski i franscuski i sve ide na dva jezika - web, izvestaji, forme, aplikacije, novine, djacke knjizice, bukvalno sve. Imamo neke tabele, koje smo nasledili iz proslosti sa poljima Eng i Fre. Sad, treba mi neki izvestaj, ja moram da radim dva izvestaja, jedan za E jedan za F. To je naravno dva kverija, dva kompletna izvestaja, ista a tako razlicita. A izvestaja ima bezbroj, apliakacija takodje. I sve mora da se radi u dve kopije, jednu za E jednu za F, odjedamput. Za ono sto smo normalizovali (varijanta 2), imamo po jedan izvestaj, po jednu aplikaciju i samo se labele prevode tako sto se citaju iz tabele. O jeziku i ne razmisljamo. Saljemo parametar u SP ili kroz Access i samo zuji.

Varijanta 2 je normalizovana, dok varijanta sa poljima za svaki jezik pada na 1NF ili u najboljem slucaju 2NF. A sve sto nije normalizovano jeste ne-normalizovano :-) i kao rezultat zahteva mnogo vise rada i proizvodi mnogo vise gresaka. Ponekad mislim da je umesto normalizovano stanje baze bolje koristiti rec normalno. Onda bismo imali normalno i nenormalno stanje baze, sto je blize stvarnosti.

:-)

Odgovor na temu

misk0
.: Lugano :. _.: CH :.

SuperModerator
Član broj: 634
Poruke: 2824
*.adsl.ticino.com.

ICQ: 46802502

+49 Profil

Re: Organizacija višejezičkih sadržaja

^{18.04.2006. u 13:04 - pre 219 meseci}

Slozio bih se sa vecinom napisanog, tj da je varijanta 2 najbolja. Poprilicno dobro funkcionishe.
Takodje varijanta 3 je OK i slanje parametara moze biti i 'jezik' tako da recimo
polje_jezik = polje + parametar_jezik"
i to opet moze da ide u stored proceduru i slicno.

Ono za sta varijanta 3 je losha je ukoliko ima vishe polja koja se prevode, tj recimo
naziv
naslov
opis_kraci
opis_duzi
detalji
....

i onda ima recimo 6 osnovnih polja, puta 3 jezika = 18 polja.. previshe.

Varijanta 2 je najoptimalnija.

:: Nemoj se svadjati sa budalom, ljudi cesto nece primjetiti razliku ::

Odgovor na temu

jablan

Član broj: 8286
Poruke: 4541

+711 Profil

Re: Organizacija višejezičkih sadržaja

^{18.04.2006. u 13:20 - pre 219 meseci}

Citat:

misk0: Takodje varijanta 3 je OK i slanje parametara moze biti i 'jezik' tako da recimo
polje_jezik = polje + parametar_jezik"
i to opet moze da ide u stored proceduru i slicno.

Može da ide u stored proceduru ako se u stored proceduri generiše dinamički SQL, a to je smrt za traženje bagova ("SQL server nije javio grešku kad sam uradio ALTER PROCEDURE? Pa normalno kad je sav SQL u string promenljivoj...") i bilo kakve kasnije izmene. A verovatno i za performanse (prekompajliranje procedure otpada).

_{[Ovu poruku je menjao jablan dana 18.04.2006. u 14:21 GMT+1]}

Odgovor na temu

Zidar
Canada

Član broj: 15387
Poruke: 3085
*.eqao.com.

+79 Profil

Re: Organizacija višejezičkih sadržaja

^{18.04.2006. u 13:56 - pre 219 meseci}

Slazem se da u stored procedure sve moze da se uradi, pa i da se promeni SELECT statement koja daje izvor za nekakav report. To isto moze da se uradi i u bilo kom externom jeziku. Linkijes SQL tabele u Access, i onda napravis kveri koji ima polje sa izrazom naslov: iif([sqlTabela].[Jezik]="E",[sqlTabela].[Naslov_Eng],[sqlTabela].[naslov_Fre]). Sve moze, naravno da moze, samo je pitanje da li je to dobro, ili dovoljno dobro na duzi rok.

Stored procedure i nisu u stvari deo relacione teorije. I one su kao neka vrsta front enda, samo sto je kod spakovan unutar samog SQL-a. Relacioni sistemi nisu proceduralni, a stored procedures jesu upravo to. Stored procedures ne garantuju integritet podataka. Niko ne garantuje da ce klijent aplikacija da upotrebi stored proceduru. Pao je predlog da se pred svako izvrsavanje po potrebi modifikuju skripte, bilo za stored procedures, bilo za view, ili cak i za tabelu. Misko je poboljsao predlog time sto zeli da sama procedura modifikuje skriptu na osnovu poslatog parametara. Sve to moze, ali u svakom koraku postaje komplikovanije i komplikovanije. AKo neko nekada pozeli da doda novi jezik, sledi prerada svih procedura, koje su vec dovoljno zakomplikovane.

I naravno, u zivotu uvek imas vise od jedne kolone kojoj treba prevod. Zasto bi samo naslov bio na francuskom a sadrzaj ostao na engleskom? Znaci, bice vise od jedne stvari da se prevodi, garantovano. A i broj stvari koje treba prevesti ce svakako rasti u buducnosti. Zamislite web site koji nudi srpsku sljivovicu i maline na prodaju u Evropi. Treba vam mnogo jezika, a i broj proizvoda koji se prodaju se stano menja, dodajuse novi, izbacuju se stari. Na sta treba da lici stored procedura ili nenormalizovana tabela koja ce sve to da podrzi?

Odgovor na temu