|
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 |
|
26. 03. 2008. | #1 |
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 04:49. |
26. 03. 2008. | #2 |
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. |
|
|
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. 09:32 |
Kako izvuci podatke iz query-a | vidak | Programiranje | 0 | 13. 01. 2008. 09:34 |
Razvoj višejezičnog sajta | Dušan Dželebdžić | Planiranje i usability | 16 | 29. 07. 2006. 23:09 |
Google u spam bazi? | bluesman | Web aplikacije, web servisi i software | 5 | 15. 01. 2006. 01:51 |