DevProTalk

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


Idite nazad   DevProTalk > Web development i web aplikacije > PHP
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

PHP PHP aplikacije, Smarty, PEAR

Odgovori
 
Alati teme Način prikaza
Staro 28. 10. 2009.   #11
DakiPro
novi član
 
Datum učlanjenja: 20.03.2006
Lokacija: Novi Sad
Poruke: 7
Hvala: 0
0 "Hvala" u 0 poruka
DakiPro is on a distinguished road
Pošaljite ICQ poruku za DakiPro Pošaljite poruku preko Skype™ za DakiPro
Default

Da, kontam poentu, svi prevodi idu u jednu tabelu, samo mi ona jedna tabela nije opravdavala postojanje. Inace, i dalje verujem da je broj 3 bolji, da li sto stare navike tesko umiru sta li je
DakiPro je offline   Odgovorite uz citat
Staro 28. 10. 2009.   #12
Bojan Zivanovic
profesionalac
Professional
 
Avatar Bojan Zivanovic
 
Datum učlanjenja: 06.06.2005
Lokacija: Pančevo - Pariz
Poruke: 287
Hvala: 6
8 "Hvala" u 8 poruka
Bojan Zivanovic is on a distinguished road
Pošaljite poruku preko Skype™ za Bojan Zivanovic
Default

Varijanta sa kolonama za svaki jezik mi je malo neprakticna.

Posto sam imao situaciju da treba da se podrzi veci broj jezika, i da to naravno treba da bude sto fleksibilnije, ishao sam na opciju da za svaki jezik imam odvojeno tabelu (content_page_sr, content_page_en, content_page_de), za jedan content item po red u svakoj tabeli, sa zajednickim content id-em (koji je sekvenca i cuva se negde druge i incrementuje po potrebi).

Onda prosto uzmem $currentLanguage i mogu da zatrazim SELECT * FROM content_page_$currentLanguage i vozi...
Povecan je broj kverija prilikom add/edit-a, ali su to ipak operacije koje imaju mali udeo u celoj prici. YMMV

Prednost je u velikoj fleksibilnosti po pitanju broja polja i slicno.
Mana je sto prilikom dodavanja novih jezika pored kreiranja tabele treba kreirati i po red za svaki postojeci content item.

Sve u svemu, ovo mi se pokazalo kao najbolje resenje do sada.
__________________
The knack of flying is learning how to throw yourself at the ground and miss.
Bojan Zivanovic je offline   Odgovorite uz citat
Staro 28. 10. 2009.   #13
mb_sa
profesionalac
Qualified
 
Datum učlanjenja: 19.05.2007
Poruke: 123
Hvala: 13
3 "Hvala" u 3 poruka
mb_sa is on a distinguished road
Default

Ja stvarno ne vidim ni jednu prednost ovakve strukture (jedino ako bas ima PUNO redova, pa ako je cilj da se izbjegne da stavlja sve u jednu tabelu). Zar ti tabela sa kolonom languange_id ti nije prihvatljivije rješenje?

Poslednja izmena od bluesman : 28. 10. 2009. u 22:20. Razlog: Obrisan nepotreban citat
mb_sa je offline   Odgovorite uz citat
Staro 29. 10. 2009.   #14
Miroslav Ćurčić
mV
Certified
 
Avatar Miroslav Ćurčić
 
Datum učlanjenja: 22.08.2009
Lokacija: Novi Sad
Poruke: 67
Hvala: 0
16 "Hvala" u 13 poruka
Miroslav Ćurčić is on a distinguished road
Default

Za potrebe jednog projekta gde je trebalo omogućiti velik broj jezika (10-15) ali gde je procena da većina tekstova neće uopšte biti prevedena izveo sam sledeću varijantu:

Sve varijante (prevode) teksta sam spojio u jedan string, upotrebivši neki "delimiter" koji se ne pojavljuje u normalnom tekstu, dodavši prethodno svakom prevodu dvoslovnu oznaku jezika kao prefiks,
i takav string snimio u tabelu, polje tipa longtext,
čak u istu tabelu sa ostalim sadržajima stranice, dakle nema posebne tabele za prevode.

Pri prikazivanju stranice naravno, dovućiće se iz baze i nepotrebni prevodi, ali kao što rekoh većina sadržaja ima u 1 ili 2 jezika. PHP je taj koji će explode-ovati taj zapis, potražiti ima li ga u traženom jeziku, ako ga nema potražiti ga u "default" jeziku sajta, a ako nema ni takvog prikazati u bilo kojem prevodu.

Važno je napomenuti da ne prevedene tekstove uopšte ne snimam u taj zbirni string. Jednostavno ih nema.

Takvim pristupom sam dobio jednostavan mysql query, bez join-ovanja i bez kontrolne logike tipa "a ako nema u tom jeziku", ili dupliranja zapisa neprevedenih tekstova.
Mislim da sam žrtvujući malo veći transfer dobio na brzini izvršavanja querija.

Dodavanje novog jezika ne zahteva nikakvu intervenciju u bazi, jednostavno će stranica prikazati default prevod jer u novom jeziku nema ništa.

U situaciji da se očekivalo da će većina tekstova biti prevedena na tih 10+ jezika išao bih na varijatu koja mi se pokazala uspešnom:
Kôd:
CREATE TABLE IF NOT EXISTS `multilang_texts` (
  `mltKey` varchar(32) NOT NULL,
  `mltLang` char(2) NOT NULL,
  `mltTranslated` char(1) NOT NULL,
  `mltText` longtext NOT NULL,
  UNIQUE KEY `mltId` (`mltKey`,`mltLang`)
);
Svi neprevedeni tekstovi se dupliraju (pišu u bazu) i ne dobijaju fleg na `mltTranslated`.
Kad se edituje tekst u default jeziku, tekst se piše i u sve zapise bez tog flega.
Kad se edituje tekst u alternativnom jeziku (prevod), postavlja se taj fleg da se više ne dira.

Poslednja izmena od Miroslav Ćurčić : 29. 10. 2009. u 12:22.
Miroslav Ćurčić je offline   Odgovorite uz citat
Staro 29. 10. 2009.   #15
Bojan Zivanovic
profesionalac
Professional
 
Avatar Bojan Zivanovic
 
Datum učlanjenja: 06.06.2005
Lokacija: Pančevo - Pariz
Poruke: 287
Hvala: 6
8 "Hvala" u 8 poruka
Bojan Zivanovic is on a distinguished road
Pošaljite poruku preko Skype™ za Bojan Zivanovic
Default

Citat:
Originalno napisao mb_sa Pogledajte poruku
Ja stvarno ne vidim ni jednu prednost ovakve strukture (jedino ako bas ima PUNO redova, pa ako je cilj da se izbjegne da stavlja sve u jednu tabelu). Zar ti tabela sa kolonom languange_id ti nije prihvatljivije rješenje?
Slazem se da je to resenje sa language_id prihvatljivo, dobrih resenja zna da bude > 1, mi smo izabrali jedno i pokazalo se ok u praksi. Sledeci put za sledece zahteve ce to mozda izgledati drugacije. Uvek je kljucno ono: YMMV

Redova inace zna da bude puno (mada se i to moze resiti na druge nacine..).

Na sta treba paziti kod implementacije language_id kolone:
Ako imam language_id kolonu, i dva reda za dva jezika, onda jedan content item nece imati jedan vec 2 id-a (sto iskljucuje mogucnost istog url-a sa prefixom ili poddomenom koji oznacava jezik).
Znaci da moram da imam jos jednu kolonu koja sadrzi generisanu sekvencu za svaki content item i koja grupise sve jezike.
__________________
The knack of flying is learning how to throw yourself at the ground and miss.
Bojan Zivanovic 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
TOP 20 MySQL Best Practices dinke SQL baze podataka - Sponzor: Baze-Podataka.net 11 26. 11. 2009. 11:26
Multilanguage wordpress site blackshtef Web aplikacije, web servisi i software 12 11. 11. 2009. 14:49
PHP Stilovi pisanja aplikacija (Best design practices) ppavlovic PHP 26 10. 07. 2007. 16:43
Performance Tuning Best Practices for MySQL Ilija Studen SQL baze podataka - Sponzor: Baze-Podataka.net 1 13. 08. 2006. 17:20


Vreme je GMT +2. Trenutno vreme je 01:02.


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.