pomoc oko multilingual select * upita

Imam dve tabele t1, t2. t1 ima neka polja, t2 ima polja koja se prevode.
t1: id, col1, col2, ...
t2: t1_id, lang_id, trans1, trans2, ...

Normalan inner join daje lepe rezultate kad mi treba jedan jezik.


Da li je moguce sql upitom dobiti ovakav rezultat za jedan t1 red (where id = 1)


Tj sa svi prevodi budu objedinjeni i u jednom rezultatu.


Predpostavljam da trazim nemoguce. Ako je to slucaj, za (where id = 1) mogu lako da napakujem trazene podatke relativno jednostavnim sabiranjem nizova. Samo mora da se pazi da t1 col nikad nemaju ime jezika koji se koristi u t2.

Sta raditi kad mi trebaju svi redovi? Znam da mogu da radim select * from t1 i select * from t2, i onda programerski pakujem, ali to mi se ne dopada. Ti nizovi mogu potencijalno da narastu + imam osecaj da nesto ne radim kako treba. Tj da mi izmice bolje i pravilnije resenje.

Potpis

I'm not in this world to live up to your expectations and you're not in this world to live up to mine.

Da, uobičajen način je da uradiš JOIN i čitaš red po red za jedan ID.


Ovo ne razumem šta si hteo da kažeš.


Isto radiš JOIN i praviš strukturu u memoriji kako ti dolazi red po red. Naravno, to u slučaju da želiš da iskoristiš sve redove. Nisi nigde napisao najbitniju stvar - kako želiš da koristiš podatke koje dobiješ od upita.

ako ti trebaju "svi" redovi to ce da te kosta isto nebitno dal na strani
baze ili na strani aplikacije ali negde ces morati da platis .. cena je
vise manje ista tako da radi tamo gde umes brze i lakse ... no pitanje
da li ti trebaju svi redovi :D

> id, col1, col2, ... [lang_id1 => [trans1, trans2, ...], lang_id2 =>
[trans1, trans2], ...]

ovo je struktura koja je vise nego dvodimenzionalna, mysql moze da ti
vrati samo i iskljucivo dvodimenzionalnu strukturu tj matricu
mozes sa group_concat da donekle simuliras trecu dimenziju ali to je
sve, pogledaj da li ti group_concat radi posao

inace to je uzasna struktura baze koju si pokazao, ako je jos u dev
stanju menjaj to to nista ne valja tako kako si nacrtao

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Prvo ide prikaz u tabeli. Najverovatnije uz neku paginaciju.
Onda dvoklik na red omogucava editovanje bilo kog polja.


Ako t1 ima polje en_US ili sr_RS ne mogu u rezultatu da imam
res = [t1.col1, t1.col2..., t1.sr_RS, sr_RS => [t2.col1, t2.col2...], en_US=>[]]
Prosto php assoc key mora biti unique. Ili cu ga pregaziti sa vrednostima iz t2.



Ok, znaci ne moze ono sto sam ja umislio. Blokirao sam sebe razmisljajuci u jedinstvenom PDO::fetchAll() pravcu!
Idem na fetchALL iz jedne tabele, pa fetchAll iz druge tabele i sabiram ih. Hvala

(Ovo sam bezuspesno pokusao da posaljem sinoc) ES je rekao Error na belom ekranu
-------------------------------------------------

Za bogdana:

Ma ne trebaju mi svi svi redovi. Lako cu da stavim LIMIT na 20, max 50 redova. Smeta mi sto moram da sklapam strukturu jer mi zaista treba select *. iz t1 i t2. Cak i ako se ne edituju sve t1 i t2 kolone, moraju sve da se prikazu.


Brate, rado cu izmeniti sve! Samo reci na sta treba da lici db za visejezicke sajtove
Tu strukturu sam nasao ovde. Gledao sam na stackowerflow, po nekim forumima i manje vise se svi vracaju na onaj link.

Njihov prvi nacin umem, i imam manje vise ceo cms za to. Mana je dodavanje novog jezika + to znam da uradim pa reko da naucim nesto novo
Drugi nacin mi se gadi.
Treci je mysql ok, ali ima zajebane insert i update sa cms strane + par likova je reklo da ce silni JOINi prilicno da opterete/uspore bazu.
Onaj cetvrti je kao najbolji odnos komplikovanost-brzina. I stvarno je ok za select * where id=$id. Deluje mi 'ruzno' kad moram da lepim t1 + t2.
U sustini ok je i ovakav rezultat:
t1.col1, t2.col2, ..., t2.col1_sr, t2.col1_en, ...

Potpis

I'm not in this world to live up to your expectations and you're not in this world to live up to mine.

Pristup 4 je OK, koristio sam ga u nekoliko projekata.

Što se tiče toga da sve moraš da prikažeš u tabeli, da li si razmišljao da ih možda
prikažeš grupisano, em je lakše napraviti, em je prostije/jasnije korisnicima nego
da pivotuješ po svim mogućim jezicima? Nešto ovako:

@dusans
Pazi kad nisam! Isao sam u pravcu jedne velike tabele... pa prikaz svega, jer vec imam cms za to.
Ali moze se i ovo napraviti. Ako bogdan ne izbunari neko extra kvalitetno resenje, radim tvoju varijantu.

Potpis

I'm not in this world to live up to your expectations and you're not in this world to live up to mine.

multiling sajt koji ima multiling content ili koji ima multiling interface ...

ovo sto si ti crtao do sada koliko vidim je multiling interface a ne multiling content

ako ti treba multiling content onda kakav content? artikli? proizvodi? komentari?

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

@bogdan:
Content na vise jezika koji se edituje. Za sada u bazu ide text (vchar 2000) , neke vesti, naslovi (vchar500), plus "nesto nedefinisano, al znamo da ce nam to trebati pa ti ostavi mesta da se to doda."

Ako pod "interface" stavimo staticke delove strane tipa title, menu, h1-h6 naslovi, footer itd onda to ne ide u bazu.
Ranije sam koristio gettext() koji se pokazao ok za interface, al sam se nesto smorio sa PoEditom i presao na obican multidim array i jednu jedinu staticku funkciju koja mi daje zeljeni prevod. Nema razlike u brzini, ali se nekako bolje osecam sa mojim statickim nizom. Ja ga napravio, ja ga editujem, menjam f() po potrebi, ne moram da se smaram kako je server podesen, sto sad ne radi gettext a u lokalu radi itd.

Potpis

I'm not in this world to live up to your expectations and you're not in this world to live up to mine.

pa nema sta onaj sajt sto si nasao (apphp) ti je dao 2 odlicna resenja (v3 i v4), ja licno volim v3 (tj nesto slicno kao v3, ja pravim object/attribute tabelu gde onda attribute tabela ima sama u sebi sve prevode slicno kao v3, nije preterano popularno resenje posto zahteva paznju i dosta je podlozne greskama kod pocetnika), v4 je isto popularno a odlicno resenje .. v1 i v2 realno nisu resenja nego greske koje se mogu naci u divljini i pored v1 i v2 ima jos desetak isto toliko cestih gresaka koje ljudi prave kada rade neki ml sajt .. nije mi samo jasno, ako si vec citao to na apphp i verovatno na jos par sajtova, kako pored svega toga napravi taj urnebes sa _lang1, _lang2... ?!

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Pa nisam :) Rekoh da moze i to da posluzi.

Svestan sam da V4 ima lep select za jedan prevod. Meni treba grupisan select za sve prevode. Posto toga nema, pravim sabiranje oba rezultata.

Jedno vazno pitanje posto si radio V3 i imas iskustva s tim. Kakve su performanse, koliko ti multi join 'koce' db itd?

Potpis

I'm not in this world to live up to your expectations and you're not in this world to live up to mine.

regularno ti treba jedan jezik, 99.99% upita ti uvek treba samo jedan
jezik... to sto ti u 0.01% trebaju svi jezici ne treba prema tome da
dizajniras sistem ... tako da napravis sistem da valja za tih 99.99% a
za taj app za prevodjenje ili za sta ti vec treba to da prikazes sve
jezike odjednom, to budznes kako god vec moras

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Skroz si u pravu :)

Kako se tebi pokazao V3 u praksi? Pitam jer sam slusao par ljudi koji su odustali od toga i presli na V4 jer im je bio previse spor.

Potpis

I'm not in this world to live up to your expectations and you're not in this world to live up to mine.

sta znam, to sto sam ja radio nije ni v3 ni v4 vec nesto slicno kao v3 .. to je opsti primer sto su ljudi stavili a ti sad tu mozes svasta da dodas i oduzmes ... idi slobodno sa v4 nista realno ne gubis ..

takodje svi ti veliki ml sistemi najmanji problem imaju sa tim da izvuces objekat iz baze na ovom i onom jeziku, tu ima toliko toga pored sto uzima resurse da je to relativno beznacajna stvar .. tako da bazu siljis prema "globalnoj slici" a ne prema jednom feature-u.... ja sam radio blize v3 nego v4 zato sto mi je tako za ceo projekat obicno lakse, a brzina baze obicno nije kriticna posto se ionako sve zivo kesira, sto u memcached, sto u redis-u sto ispred svega na nginx-u .. na primer, nevezano za multilang, pogledaj ooyyo.com (nije reklama posto je srbija ukinuta iz ponude pre par meseci), uradi bilo koju pretragu, pogledaj sa leve strane filtere, mysql koji generise te filtere na toj strani uzima 99.92% vremena generisanja te strane a 0.08% je *sve* ostalo! .. i onda kako je dizajnirana baza za taj sistem, pa dizajnirana je da filteri rade brzo, sve ostalo je sekundarno

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Hvala svima na odgovorima :)
Radim 4 i budzim ono sto se budziti mora.

Potpis

I'm not in this world to live up to your expectations and you're not in this world to live up to mine.