Kako držati višejezične podatke u bazi...

[McChoban]

...a da to ima smisla, logike i elegancije?

Ovo sve gledam kroz perspektivu nekog potencijalnog ORM-a koji bi morao da tadi s takvom bazom.

Dakle, primera radi imam objekat koji poseduje podatke
id, url, opis

Naravno, od ovoga jedino opis bi trebalo da bude visejezican.

E sad, koliko ja vidim resenja koja se namecu su:

1. da napravim dodatnu tabelu gde se čuvaju opisi pa da vadim preko joina (ovo mi je malo glupo i deluje nepraktično)

2. da stavim posebno polje za svaki jezik (zvale 90-e i tražile svoju bazu natrag, plus moram da alterujem tabelu svaki put prilikom brisanja ili dodavanja jezika)

3. da imam compound key-eve od id-a i jezika, pa da ih po tome pretrazujem (ali onda se 'zajedički' podaci, poput url-a u ovom slučaju, ponavljaju...)

4. ???


p.s. "rešenje" koje viđam po dosta sajtova, a to je da sve prevode potrpaju u jednu tabelu pa ih vade preko neke relacije, ne bih pominjao...

[bluesman]

Prvo pitanje je koliko jezika planiras da podrzis, ako je 2 onda moze svakako, i mozda je bolje imati u istoj tabeli oba jezika

Ako imas vise, pa jos ako je promenljivo... onda je bolje praviti language tabele... na primer, ja sam jednom koristio sistem gde pre nego sto definisem kako se zove tabela, proverim koji je jezik , ako je engleski dodam na ime tabele _en ako je srpski, dodam _sr, ali to onda znaci da moras da imas po 2 tabele za sve zivo sto je cimanje.

Najbolje resenje je imati posebne language tabele i u njoj index language char(2) i onda radis uvek joinove, ne znam bolje resenje za sisteme sa vise od 3 jezika i gde je taj broj promenljiv. Znaci drzis jednu fast tabelu u kojoj su osnovni indexi i ono sto se ne prevodi, na primer DATE ili neki counter ili nesto... a za svaku imas dodatnu tabelu u kojoj je primary key (id, language)

I da... ako ces da budes gadljiv na "ne-lepa" resenja, to je dodatni problem. Ako sam nesto naucio sa mysql je da nije najbolje uvek ono sto je "by the book", narocito kod tih ref. integriteta i ostalih stvari. Sve je to lepo u teoriji ali u praksi je bolje malo "zaobici" pravila i zazmuriti na jedno oko za lepotu.

[ivanhoe]

Moje iskustvo (razvoj CMS koji se koristi na 15-tak solidno velikih visejezickih sajtova) je da je najbolja varijanta po jedna tabela za svaki jezik, plus jedna tabela koja sluzi za povezivanje prevoda (ako ti ta opcija uopste treba). Onda samo za imena tabela koristis promenjive koje se na pocetku skripte setuju zavisno od trenutnog jezika i sve funkcije ti potpuno transparentno rade bez obzira na trenutni jezik jer su sve tabele identicne, a jezik ti nije bitan parametar u kodu. To dosta pojednostavi neke ceste operacije, jer ne moras da vodis stalno racuna o trenutnom jeziku i da to guras u svaki upit na bazi..

Moze da se uradi i normalizacija pa da imas odvojenu tabelu za zajednicke podatke, kao sto blues kaze, ali onda imas jedan JOIN vise, a obicno je tih zajednickih podataka jako malo, pa i ne stedis nesto bitno. Takodje ja sam paranoik poucen losim iskustvima, pa umem da cenim duplirane podatke. Ako nesto pukne pa se zezne ref. integritet baze, mnogo je lakse rekonstruisati stvari kad su podaci donekle duplirani, nego kad je sve skroz normalizovano. A i brze radi.

[Dejan Topalovic]

Ne slazem se sa potencijalnim rjesenjima cijenjenih kolega, jer se predlozenim rjesenjima OSNOVNI zadatak baze pokusava prebaciti na aplikaciju - koristenje vise tabela (za svaki jezik po jedna), spremanje vrijednosti odabranog jezika u neku varijablu, pa dinamicki odabir tabela i td.

Slazem se sa izjavom da nekad ne treba bas sve po knjigama raditi, odnosno da ne treba normalizovati podatke u tabelama do najsitnijih detalja i referenci, ali do tih slucajeva se dolazi uglavnom u odredjenim situacijama...

Evo kako smo mi odradili visejezicnu podrsku u nasoj bazi - uzecu npr. fondove, jer imamo visejezicnost za mnoge stvari:

1. imamo glavnu tabelu sa fondovima (fund_id, name, ... )
2. imamo tabelu sa opisima fondova na vise jezika (surogatni_id, fund_id, language, fund_description, ...)

E sad, posto smo spomenuli normalizaciju i denormalizaciju, ovo je idealan primjer denormalizacije. Naime, mogli bismo kreirati jos jednu tabelu za jezike (jezik_id, naziv_jezika, oznaka), pa ju onda koristiti u JOIN dijelu, ali posto je broj koristenih jezika veoma mali, ne isplati se cuvati informaciju o koristenim jezicima.

Znaci, ako nam na njemackom jeziku treba opis fonda pod brojem 11, onda upit izgleda ovako:

SELECT fund_description
FROM funds_descriptions
WHERE fund_id = 11
AND language = 'DE';

Ukoliko bismo koristili jos jednu normalizovanu lookup tabelu sa jezicima, onda bi upit izgledao ovako:

SELECT fd.fund_description
FROM funds_descriptions fd, languages l
WHERE l.language = 'DE'
AND fd.language_id = l.id
AND fd.fund_id = 11;

@McChoban: Tebi treba jedna language tabela sa poljima (id, ref_id_iz_prve_tabele, jezik, opis, ...), npr. imas u prvoj tabeli ove podatke:

ID     URL 
---   --------------------------------
   1   http://www.baze-podataka.net/
   2   http://www.devprotalk.com/

I sad zelis da za URL pod brojem 2 imas opise na vise jezika ukljucujuci engleski, njemacki i td., na osnovu cega u ovoj novoj tabeli imas podatke:

ID    URL_ID   JEZIK    OPIS
---   -------  ------   ------------------------------------
  1        2      EN    This is just a dummy description ...
  2        2      DE     Das ist nur eine dumme Beschreibung ...
  3        2      ??     lorem ipsum ...

Dakle, onaj posao - za koji su baze namijenjene - treba bazama prepustiti i ne izmisljati toplu vodu...

[ivanhoe]

ja sam radio jedan CMS u kome je primenjeno ovakvo resenje kao sto Dejan predlaze, ali sam posle odustao od toga i razdvojio tabele za svaki jezik posebno i meni se cini da je to meni pojednostavilo kod, ne vidim to kao prebacivanje posla sa baze na skript, jer ionako skript mora da odluci koji je jezik u pitanju, i mora na pocetku da setuje imena tabela (bar ja nikad ne hardkodujem imena tabela), tako da nema nikakvog extra posla u kodu, bas naprotiv.

Po meni prednosti su:
- Nigde u kodu ne mora da se explicitno zadaje "AND language = 'DE'", sto je inace moralo da postoji napisano u apsolutno svakom upitu (i mora u kodu da se o tom parametru vodi racuna). Najveci deo koda ne mora uopste da zna koji je trenutni jezik, sve se radi univerzalno, sto donekle olaksava pravljenje pluginova.

- Olaksava se masovno prevodjenje, jer se svodi na prosto kopiranje cele tabele i onda update vrednosti koje zelis da prevedes. Kad imas neke komplikovanije strukture tipa kategorija to je solidno jednostavnije uraditi nego kad se sve nalazi u istoj tabeli (parent ID-jevi ostaju isti u obe tabele, pa ne moras uopste da brines o strukturi podataka, ona je vec odradjena, samo linearno prevodis podatke)

- Za dovoljno velike tabele ce postojati razlika u brzini upita, jer ako koristis samo jednu tabelu, za 3 jezika imas 3-ko vecu tabelu, plus mora svaka tabela da ima index i po language polju..

Mane kojih sam svestan:
- Ako postoji potreba za dohvatanjem podataka na raznim jezicima istovremeno, to je sporije, jer su u razlicitim tabelama, i mora da postoji dodatna logika da se imena tabela setuju kako treba. Ali meni nikad to nije trebalo, pa me ne pogadja..

- Povecava se broj tabela, pa ako bi bilo puno jezika, plus puno tabela inace, i svaki od tih delova sajta bio dosta posecen, moglo bi da se desi da mysql krene da trosi puno vremena otvarajuci i zatvarajuci tabele i da mu keshiranje ne radi lepo. Ali opet to je cisto teoretski..

just my $0.02, naravno, zanimljivo je cuti i druga resenja..

[zira]

Koristio i jedno i drugo rjesenje. Za vecinu sajtova (citaj 2-3 jezika) mi je draze rjesenje sa posebnom kopijom tabele za svaki jezik (sa dupliranim podacima).
Ovo sto ivanhoe kaze, jeste zahtjevnije ako trebas povuci podatke za svaki od jezika odjednom, ali takvi upiti su znacajno rjedji od onih klasicnih za koje je potreban samo jedan jezik.

[Milos Vukotic]

Po potpuno istom principu sam pravio svoje višejezične sajtove i neke aplikacije s vremenskom prognozom.

Ipak, ne slažem se da tabela s jezicima nije isplativa, korisna je kad pravis menije, bilo za unos ili prikazivanje sadržaja, jedan query za jedan select box i miran si