Visejezicni sajt - osmisljavanje baze?

Kako biste vi osmislili bazu za multilanguage support, sta bi bilo najbolje, najbrze?
Radim neki sajtic gde bi trebalo da imam 4 jezika... Da li da za svaki pravim posebnu tabelu, ili mogu sve da turim u jednu tabelu poput ove:

id
english_title
en_short_desc
en_long_desc

ger_title
ger_short_desc
ger_long_desc

fr_title
fr_short_desc
fr_long_desc

spanish_title
sp_short_desc
sp_long_desc

main_photo

?

Kao sto vidite, relativno malo tekstualnih podataka je u pitanju (prikaz nekih vila je tema), imam ime vile/imanja, kraci i duzi opis...

Hvala!

Moja preporuka da radis dve tabele,

id
main_photo

druga sa prevodima

fk_id
fk_language_id
title
short_desc
long_desc


Gde su ti fk_id i fk_language_id (fk = foreign key) primarni kljucevi, i ovako onda mozes imati xx jezika a uvek samo izvadis joinovane podatke za ID koji listas i ID jezika koji se trenutno koristi.

Potpis

http://norway.dakipro.com/

ja licno nebi ni na prvi ni na drugi naci nego nesto ovako:

id
sid
title
short_desc
long_desc
jezik


jezik ti sluzi za tip jezika npr en, fr, ger itd tako da lako mozes selekovati samo taj tip jezika

Potpis

Aj sad svi u biblioteku da nesto pojedemo i popijemo ...
--------------------------------
Knjigovodstvo

A sta je SID kod tebe?
Takodje, odakle bi vadio sliku, ili dodatne podatke o glavnom rekordu kasnije, recimo is_active, create_date i to? ako ih ubacuje za sve jezike dobija redundantu, i to ne bas malu, nego 4x vecu.
I posle bi bilo malo nezgodna manipulacija njima, ako promeni sliku ili nesto drugo, morao bi da juri za sve prevode i da to radi (kao i sa svakom redundancom)

Potpis

http://norway.dakipro.com/

Hvala, ljudi.

@dakipro, sad nesto razmisljam...
Imam i jednu tabelu samo sa slikama:
id, property_id, photo

(Svaka vila/imanje bi trebalo da ima najvise 10 slika)

Dakle, da li da ovo menjam, ili da ostavim ovu tabelu?

U tom slucaju bih, ako prihvatim tvoju sugestiju, imao tri tabele...

Pa to mozes sa ovim resenjem sto sam ti ja pisao, jer imas jasno ID koji je property, a i lakse je za nadogradnju, jer klijent u 99.999999% uvek doda neko polje u zadnji trenutak. To je valjda druga ili treca normalizacija baze (uvek bio los sa teorijom :( )
Sad, ovo je nacin kojim su mene ucili, nisam ja izmislio to pa da se drzim toga ko blesav, ako mislis da bi ti vise odgovaralo tvoje resenje ili ovo koje je Radovan__III postovao, ti idi kako ti je tebi najlakse. Samo ja i dalje vidim velike prednosti razdvajanja entiteta ovako po tabelama. Ne mora to biti slika, jos je bolje sto imas slike u posebnoj tabeli jer nisi ogranicen kolicinom slika po propertiju, ali recimo ako bude klijent dodao (a sve agencije to imaju) polje recimo internal_code koje njima samo sluzi za interno belezenje properija, to bi polje logicno islo uz glavni entitet, tj, u property tabelu, nevezano za prevode, nije ni prevodivo. Ili recimo polje is_special kasnije kad se klijent izmisli da hoce neke da chekira i oni da se pojave na home-page.
Cisto je iskustvo pokazalo meni i drugima velike prednosti ovakvog odvajanja entiteta, a broj tabela je nebitan, nemas tu nikakvo ogranicenje. Ako je potrebno dodati nekoliko fajlova uz propery, napravis novu tabelu ako ti ne odgovara da drzis sve u tabelu sa slikama, ili ako je potrebno imati nekoliko video fajlova, opet isto, broj tabela nikada nemoj da gledas kao nesto lose, ako ce to ubrzati ostatak aplikacije, to je potrebno onda.
Sad jeste malo zez jer nemoz obican select da radis vec JOIN, ali nije to neka nauka takodje. A i kad posle dodas novi jezik, samo novi rekord i gotovo, a klijentu naplatis posteno svu muku :)
I to su me naucili isto :)

Potpis

http://norway.dakipro.com/

Uh, to dodavanje ne gine, to sam i ja naucio. :)
Na pocetku je sve jednostavno, par slika, malo teksta, jednostavan admin panel, hajde samo sto brze da se sklepa, i za sto manje pare, naravno. Posle sledi seks. :)




Ma vidi, ja sam tezak amater, zato sam i pitao koje je resenje najbolje. Usvajam, naravno, bolja resenja od svojih. :)
Zelim pristojnu brzinu i relativno bezbolnu ''nadogradivost''. (Necu da se posle 200-300 vila skript uspori, ili da mi jedna promena/novotarija shebe celu koncepciju, sto se desavalo, doduse ne toliko mojom krivicom):)
Za ta laksa i brza resenja se cesto kasnije ispostavi da su mnogo bolnija. :)

Usput, malo sam i ispao iz fazona, u poslednje vreme sam samo babrao po nekim starim skriptovima, pa ce biti dobra prilika da se malo osveze jadna znanja, a i taj JOIN da se savlada, vec jedared :) ...

A evo i ja da predložim jedno neobično rešenje za realizaciju multi-jezičnosti...

Naime, moja ideja bi se svodila na to da se ti tekstualni podaci - title, short_desc, long_desc, čuvaju u JSON formatu (verovali ili ne ), jer JSON može da čuva neki niz u obliku string-a. Npr. administrator u admin panel-u unese neke stavke i naravno, sva ova polja unese na zasebnim jezicima, i nakon submit-a, to se "spakuje" u neki ovakav niz:

I tako i za druga dva polja, short_desc i long_desc.

Posle se to samo prebaci u JSON - $tekst = json_encode($niz);, i dobija se ovakav string:
{"en":"Naslov na engleskom","ger":"Naslov na nemackom","fr":"Naslov na francuskom","esp":"Naslov na spanskom"}

Na taj način, u bazi nema potrebe za id-evima jezika, spajanjima, itd., već se za svaki red u tabeli u tim tekstualnim poljima čuvaju ti stringovi, koji u sebi imaju niz.

I onda recimo na nekoj stranici se uzima taj parametar iz URL-a koji govori koji je jezik izabran, pa kad se dohvate ti podaci iz baze za određeni id, treba samo te tekstove ponovo "otpakovati" u niz, ovako:

I to je sve...

Nikad nisam probao ovako nešto, ali verujem da bi moglo da prođe...

Moze ovo da bude ideja po meni, par stvari koje me recimo bacaju na razmisljanje, a voleo bi povesti diskusiju na temu
1. pretraga po odredjenom jeziku mi deluje nemoguca?
2. administracija pojedinacnog jezika mi dosta dodje komplikovana, recimo, klijnet oce u tabovima po jezicima da menja podatke, ono, prevod na srpskom, na engleskom posebno itd, moralo bi da se iscita sve iz baze, izmeni za trenutni jezik pa natrag u bazu?
3. Kako bi se ponasalo sa velikim podacima u opisu, recimo ima wysiwyg editor, i spici sve i svasta u njega, verujem da JSON to sve lepo escajpuje da bi odrzao svoj format, ali da li bi tu bilo previse podataka izvucenih po podatku? ono, useri izlistaju 50 properija po stranici, i tu se vadi bar 200 dugackih podataka ili tako nesto?
4. Prilikom dodavanja novog jezika, moralo bi uvek da se radi onda if (isset($label[$lang]['title'])) jer stari podaci ne bi imali taj novi jezik (ovo mysql recimo sa IF resava pa ako ne postoji prevod, odma ubaci neki drugi podataka kao title, recimo generic_title iz glavne tabele)
5. Opet se javlja neki vid redundantnosti, cita se 4x vise podataka nego sto je potrebno, jer bi svako gledao sajt u jednom jeziku uglavnom?

Potpis

http://norway.dakipro.com/

E pa to, generalno, najveći problem sa ovakvim rešenjem je to što bi se u tim poljima čuvalo stvarno previše teksta. I naravno, nije skalabilno... Odnosno, može da bude, al' to je onda više "silovanje" i prkošenje MySQL-u.

Al' opet kažem, nikad nisam probao ovako nešto, to je samo neka ideja.

Pa ima mesta za primenu, mozda ne u multilang, ali tako nesto, jer sam ja recimo do sad uvek radio serialize nad nizom da bi ga cuvao u bazi, a ovo je mozda bolje jer (mozda?) mozes i direkt u bazi menjati vrednosti, a i pretraziti ih jer su plain text. Mada, i serialize moze do nekle, ali opet, mozda ima neku upotrebnu vrednost json. AKo nista drugo, bar za neku gomilu podataka koje vadi js/ajax :)

Potpis

http://norway.dakipro.com/

@dakipro, ovo fk_id je id imanja/vile, zar ne? Ili nisam dobro razumeo?

Pa da, trudim se da drzim neku konvenciju jer mi posle lakse da znam koje je odakle, recimo tabela 'propery' ima propery_id, property_name, property_desc, kad posle joinujem sa recimo kategorijom odma znam cije je 'name' ustvari, ovamo je category_id, category_name i to. lakse posle prilikom joina, jer imam lepo property_id, cat_id. I kad vezujes recimo property za cat, imas fk_category_id, i znam odmah da je to veza, fk_ znaci da je to ID nekog drugog entiteta u bazi (Foreign Key).
Mada, cesto prilagodjavam konvenciju usput kako mi odgovara nazalost :)

Potpis

http://norway.dakipro.com/

Ok, hvala!
Krecem ovako kako si savetovao.
Slutim da cu se skenj... sa join-ovanjem, pa me eto opet, ubrzo...

Defnitivno ovako kako je Dalibor predlozio!
Ovako ali bukvalno za sve sto radite jer ovo je standard ili da eventualno idete sa hijerahijom u okviru jedne table (losijia i teza varijanta generalno gledano).

Evo i analize na prostom primeru:

langs
1 sr
2 en
3 it
4 fr
5 es
6 ru
7 ro

content
id lang_id data

1 1 zdravo
2 7 salut
3 2 hello
4 3 buongiorno
5 6 zdrastvujtje
6 4 bonjour
7 5 hola

I tako za neogranicen broj jezika, dodavanje kontenta prosto, izmene takodje (front end krajnje jednostavan ako je app template based).

I možda je još bolje (kao što je i Dalibor predložio) da u toj tabeli content ide dvostruki primarni ključ, pa bi onda imao ovako nešto:

@Nikola Posa

Zavisi iz kog se ugla gleda, ja licno preferiram nacin koji sam napisao prvenstveno zbog toga sto sam jednom imao problem upravo sa takvom strukturom i podaci su se da li greskom nekog od developera (mozda i mojom) ili necijom drugom pretumbali tj. obrisao se znacajan deo ili tako nesto. Znam da je bio prilican broj redova oko 15-16k a uz to su isle i slike koje su se imenovale po principu time().extenzija.

E onda je trebalo spasiti te slike tj. izvrsiti oporavak applikacije, naravno bilo je nemoguce, i od tada furam ovakav koncept prvenstveno zbog lakseg vracanja podataka (jer sada id + spec_karakter ide ispred svakog fajla...) i brzine jer se desava da mi nekad innodb jednostavno nije potreban...

Imam cak i jos neke razloge, koji su vise vezani sa sam frejmvork ali nisu banalni :P

Auuu :/ Ovo je dosta komplikovano.

Da li neko moze da mi eksportuje strukturu mysql-a i php kod da vidim kako treba, jer ovako nista ne razumem??Bio bi vam veoma zahvalan :)