|
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 |
|
Alati teme | Način prikaza |
|
23. 03. 2008. | #1 |
član
Certified
Datum učlanjenja: 21.06.2005
Lokacija: Beograd
Poruke: 60
Hvala: 3
4 "Hvala" u 1 poruci
|
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... |
23. 03. 2008. | #2 |
Goran Pilipović
Sir Write-a-Lot
|
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! |
24. 03. 2008. | #3 |
Ivan Dilber
Sir Write-a-Lot
|
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. |
26. 03. 2008. | #4 |
old school
Professional
|
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'; 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/ 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 |
2 članova zahvaljuje Dejan Topalovic za poruku: |
26. 03. 2008. | #5 |
Ivan Dilber
Sir Write-a-Lot
|
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. |
26. 03. 2008. | #6 |
Vladan Zirojević
Grand Master
|
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. |
26. 03. 2008. | #7 |
Knowledge base
Wrote a book
Datum učlanjenja: 07.06.2005
Lokacija: Neđe ođe...
Poruke: 1.197
Hvala: 339
688 "Hvala" u 178 poruka
|
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
__________________
Чак Норис може да си ги врзе врвките на чевлите со стапалата. |
|
|
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 |