DevProTalk

Forumi IT profesionalaca
web development, web design, e-business, SEO


Idite nazad   DevProTalk > Web development i web aplikacije > SQL baze podataka - Sponzor: Baze-Podataka.net
Beach Wedding Dresses - Looking for the Wedding Dress? Here, 1dress.co.uk stunning collection of beach wedding dresses is just what you are looking for.
charles wang

SQL baze podataka - Sponzor: Baze-Podataka.net MySQL, MSSQL, Oracle, Access, ODBC. Ako imate problem brže i preciznije ćete dobiti odgovor ako priložite strukturu tabela ili skript koji kreira tabele i puni ih test podacima umesto što to problem opisujete samo rečima. Sponzor: Baze-Podataka.net - Blog o bazama podataka

Odgovori
 
Alati teme Način prikaza
Staro 23. 03. 2008.   #1
McChoban
član
Certified
 
Datum učlanjenja: 21.06.2005
Lokacija: Beograd
Poruke: 60
Hvala: 3
4 "Hvala" u 1 poruci
McChoban is on a distinguished road
Question Kako držati višejezične podatke u bazi...

...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...
McChoban je offline   Odgovorite uz citat
Staro 23. 03. 2008.   #2
bluesman
Goran Pilipović
Sir Write-a-Lot
 
Avatar bluesman
 
Datum učlanjenja: 18.05.2005
Lokacija: Beograd
Poruke: 5.450
Hvala: 288
1.239 "Hvala" u 446 poruka
bluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušati
Pošaljite ICQ poruku za bluesman
Default

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.
__________________
Goran Pilipović a.k.a. Ugly Fingers Bradley f.k.a. bluesman
I don't always know what I'm talking about but I know I'm right!
bluesman je offline   Odgovorite uz citat
Staro 24. 03. 2008.   #3
ivanhoe
Ivan Dilber
Sir Write-a-Lot
 
Avatar ivanhoe
 
Datum učlanjenja: 18.10.2005
Lokacija: Bgd
Poruke: 5.320
Hvala: 104
1.941 "Hvala" u 579 poruka
ivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svima
Pošaljite poruku preko Skype™ za ivanhoe
Default

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.
__________________
Leadership is the art of getting people to want to do what you know must be done.
ivanhoe je offline   Odgovorite uz citat
Staro 26. 03. 2008.   #4
Dejan Topalovic
old school
Professional
 
Datum učlanjenja: 15.02.2006
Lokacija: Wien, Austria
Poruke: 304
Hvala: 121
47 "Hvala" u 26 poruka
Dejan Topalovic će postati "faca" uskoro
Pošaljite poruku preko MSN za Dejan Topalovic
Default

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:
Kôd:
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:
Kôd:
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:


Kôd:
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:

Kôd:
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...
__________________
Blog: Baze podataka
------------------------
Oracle OCP DBA
Oracle OCE SQL Expert
Oracle OCP Developer
Certified MySQL DBA

Poslednja izmena od Dejan Topalovic : 26. 03. 2008. u 02:36. Razlog: CODE tag
Dejan Topalovic je offline   Odgovorite uz citat
2 članova zahvaljuje Dejan Topalovic za poruku:
Staro 26. 03. 2008.   #5
Milos Vukotic
Knowledge base
Wrote a book
 
Avatar Milos Vukotic
 
Datum učlanjenja: 07.06.2005
Lokacija: Neđe ođe...
Poruke: 1.197
Hvala: 339
678 "Hvala" u 178 poruka
Milos Vukotic je pravi dragi kamenMilos Vukotic je pravi dragi kamenMilos Vukotic je pravi dragi kamenMilos Vukotic je pravi dragi kamenMilos Vukotic je pravi dragi kamenMilos Vukotic je pravi dragi kamen
Pošaljite poruku preko Skype™ za Milos Vukotic
Default

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
__________________
Чак Норис може да си ги врзе врвките на чевлите со стапалата.
Milos Vukotic je offline   Odgovorite uz citat
Staro 26. 03. 2008.   #6
ivanhoe
Ivan Dilber
Sir Write-a-Lot
 
Avatar ivanhoe
 
Datum učlanjenja: 18.10.2005
Lokacija: Bgd
Poruke: 5.320
Hvala: 104
1.941 "Hvala" u 579 poruka
ivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svima
Pošaljite poruku preko Skype™ za ivanhoe
Default

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..
__________________
Leadership is the art of getting people to want to do what you know must be done.

Poslednja izmena od ivanhoe : 26. 03. 2008. u 05:49.
ivanhoe je offline   Odgovorite uz citat
Staro 26. 03. 2008.   #7
zira
Vladan Zirojević
Grand Master
 
Datum učlanjenja: 09.06.2006
Lokacija: Beograd/Trebinje
Poruke: 903
Hvala: 106
183 "Hvala" u 82 poruka
zira ima spektakularnu auruzira ima spektakularnu auruzira ima spektakularnu auru
Pošaljite ICQ poruku za zira Pošaljite poruku preko Skype™ za zira
Default

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.
__________________
Donesi.com SrediMe
zira je offline   Odgovorite uz citat
Odgovori


Alati teme
Način prikaza

Pravila pisanja
Možete ne započinjati nove teme
Možete ne slati odgovore
Možete ne slati priloge
Možete ne izmeniti svoje poruke
vB kôd je Uključen
Smajliji su Uključen
[IMG] kod je Uključen
HTML kôd je Isključen
Pogledajte forum

Slične teme
Tema Početna poruka teme Forum Odgovori Poslednja poruka
Kako masovno promeniti latin1_swedish_ci u utf8 u bazi ljtruba Sva početnička pitanja 7 11. 07. 2009. 10:32
Kako izvuci podatke iz query-a vidak Programiranje 0 13. 01. 2008. 10:34
Razvoj višejezičnog sajta Dušan Dželebdžić Planiranje i usability 16 30. 07. 2006. 00:09
Google u spam bazi? bluesman Web aplikacije, web servisi i software 5 15. 01. 2006. 02:51


Vreme je GMT +2. Trenutno vreme je 03:57.


Blogodak - Domaci blogovi na jednom mestu Caught in a web - web dev blog
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.
Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.