Multilanguage db variants

[ray]

Mēģinu uztaisīt lapu ar multilanguage db un esmu iedomājies šādu variantu:

 

tabula1 - jaunumi

(id, nosaukuma_tulkojuma_id, teksta_tulkojuma_id, valodas_radit)

ar datiem

(1, 1, 2, 'lv,en')

 

tabula2 - tulkojumi

(id, tulkojums, tulkojuma_id, valoda)

ar datiem

(1, 'nosaukums latviski', 1, 'lv';

2, 'nosaukums angliski', 1, 'en';

3, 'teksts latviski', 2, 'lv';

4, 'teksts angliski', 2, 'en')

 

Ko sakāt par šādu variantu? Nebūs baigās problēmas ar ātrdarbību pie liela apmeklētāju pieplūduma?

Edited September 23, 2011 by ray

[Grey_Wolf]

1. neglabā valodas ka stringu en, lv, ru bet gan ka int 1,2,3

tas dos iespējas nakotnē pielikt n- vlodas

2. ne visiem rakstiem būs tulkojumi, attiecigi rakstu tabulai vienkarši pieliec klāt valodas _id

(nesi tāds optimists, NEBŪS visiem rakstiem pretī tulkojums, kautvai tādēļ ka vajadzigs laiks iztulkot, un kautvai primītivi viņu pievienot DB [ kamēr liksi viņu klāt var izveidoties situacija , ka k'ds jau mēģina viņu lasīt - attiecigi būs kļūda ])

[codez]

GW, pie en, ru, lv varianta jau arī var pēc tam likt klāt valodas - ge, it, es, utt.

 

Manuprā viens no labākajiem variantiem ir šāds. Izmanto templeitus priekš satura ģenerēšans, templeitos, tekstu vietā liec kādu spcieālu tagu, kurā ieraksti tulkojamā vārda identifikātoru, piemēram <t>email</t>.

Tad, kad tiek pieprasīts renderēt attiecīgo templeitu, piem., index.tpl en valodā, tad uzģenerē index.tpl.en, izmantojot db. Nākošereiz tev tikai jāsalīdzina, ja index.tpl fails ir vecāks par index.tpl.en failu, tas nozīmē, ka index.tpl.en failā ir jaunākā index.tpl tulkojums un tu vari pa tiešo izmantot index.tpl.en failu. Produkcijas serverī jau tev index.tpl fails praktiski nemainīsies un būs iztulkoti visu valodu index.tpl.xx faili. Šādā veidā, tev nebūs praktiski neviens pieprasījums uz db produkcijas serverī, bet saglabāsi ērtumu, tulkojumus liekot db. Vienīgais papildus ir vajadzīga vien komanda, ja tu maini tikai db saturu un nemaini .tpl failu saturu, tad tev ir vai nu visi jāpārģenerē, vai arī jāizdzēš, vai arī jāievieš papildus laika parametrs, par kuru vecākus failus jāpārģenerē.

 

Un attiecīgi db tabula ir:

tag, lang, text

--------------------

email, en, e-mail

email, lv, e-pasts

from, en, from

from, lv, no

 

un attiecīgi index.tpl

<t>email</t>

 

tiek pārveidots par

index.tpl.en

e-mail

 

un index.tpl.lv

e-pasts

Edited September 24, 2011 by codez

[ray]

tā template sistēma mani kaut kā nepaķēra :/

 

1) doma par valodu pievienošanu, kā jau codez teica, ir likt klāt "ru, ge, es, it" utt. un tad attiecīgi ar "LIKE valodas_radit = '%lv%' " to izgūt no db. Ko par šo saka db eksperti? nebūs problēmas ar ātrumu pie liela db ierakstu un apmeklētāju daudzuma?

 

2) domā jaunumu tabulu pārveidot uz (id, nosaukuma_tulkojuma_id, teksta_tulkojuma_id, valodas_id, valodas_radit) un tad tajā "valodas_id" attiecīgi glabāt kādās valodās tulkojumi ir pieejami/iztulkoti ?

Edited September 24, 2011 by ray

[mad182]

Lai pārtulkotu dažādus elementus lapā: http://php.net/manual/en/book.gettext.php

 

Lai tulkotu saturu (ziņas), tad vispirms ir jāatbild uz jautājumu, vai vienmēr vienādas ziņas tiks rādītas visās valodās. Varbūt vienkāršāk ir ziņu tabulā tikai pieglabāt valodu kā vienu lauku, un lai raksti paliek neatkarīgi viens no otra?

[Grey_Wolf]

1) doma par valodu pievienošanu, kā jau codez teica, ir likt klāt "ru, ge, es, it" utt. un tad attiecīgi ar "LIKE valodas_radit = '%lv%' " to izgūt no db. Ko par šo saka db eksperti? nebūs problēmas ar ātrumu pie liela db ierakstu un apmeklētāju daudzuma?

tas ka varet jau var, bet stringa meklēšana ir IEVEROJAMI lēnākā nekā INT atrašana...

piedevām normālāka datu strukturā tomēr butu , ja izmantotu ID , kurs vari arī glabāt iekš kādas atsevišķas tabulas ( nu priekš 3-5 valodām tas gan nav vērts )

piemeram : tabula - > valodas kur : ID | valodas nosaukums | komentari etcc...

[mad182]

tas ka varet jau var, bet stringa meklēšana ir IEVEROJAMI lēnākā nekā INT atrašana...

 

Nu nu...

 

http://www.mysqlperformanceblog.com/2008/01/24/enum-fields-vs-varchar-vs-int-joined-table-what-is-faster/

[Grey_Wolf]

 

Nu nu...

 

http://www.mysqlperf...what-is-faster/

es tecu STRINGA, nevis enum, jo enum jau glaba INT, (masiva indeksus) !!!

[mad182]

Nu arī varchar tur neparāda tik ievērojami sliktāku rezultātu, lai to būtu ar lielajiem burtiem jāraksta :)

 

Bet nu jā, es piekasos sīkumiem :)

[Gints Plivna]

 

Nu nu...

 

http://www.mysqlperf...what-is-faster/

Norādītā raksta rezultāti nekādi nav salīdzināmi ar to ko piedāvā jautājuma autors.

Rakstā tabulas DDL skripts ir šāds:

CREATE TABLE cities_varchar (
 id int(10) unsigned NOT NULL auto_increment,
 state varchar(50) NOT NULL,
 city varchar(255) NOT NULL,
 PRIMARY KEY  (id),
 KEY state (state)
) ENGINE=MyISAM;

Kas nozīmē to, ka uz lauku state ir indekss (norāda atslēgvārds KEY) un tajā ir tikai 1 vērtība - 1 štats. Attiecīgi lasot un filtrējot pēc štata nepieciešamības gadījumā MySQLs var lietot indeksu, ja uzskata to par vajadzīgu, t.i. tam nav obligāti jāpārlasa visi tabulas ieraksti, lai atalasītu nepieciešamos.

Autors piedāvā lauku valodas_radit, kas izskatās pēc plika varcahar lauka, kurā vērtības atdalītas ar komatu un meklēt ar konstrukciju LIKE valodas_radit = '%lv%', kur %whatever% nozīmē tikai un vienīgi tabulas pilnu pārlasi (full scan).

Kamēr tabulā ir maz datu un maz lietotāju, kas to dara viss ir OK. Ja būs daudz datu vai daudz lietotāju (vai vēl trakāk - abi divi), tad būs milzu bremze. Protams, MySQLā ir visādi tur kešoti selekti un sazin kas vēl, bet, ja būs arī izmaiņas, tad kā minimums pēc katras izmaiņas nāksies visu pārlasīt. Katrā ziņā es nekad nelietotu %lv%. Šis risinājums ir ērts un ātrs, lai vienam dotam rakstam noskaidrotu visas valodas, jo tās ir vienā laukā, bet tas noteikti nav ātrs, lai noskaidrotu visus rakstus vienā dotajā valodā.

 

Gints Plivna

http://datubazes.wordpress.com/

Edited September 26, 2011 by Gints Plivna

[Kavacky]

"%lv" izmantos indeksu, "%lv%" - ne.

[Gints Plivna]

"%lv" izmantos indeksu

otrādi - "lv%"

Un pareizi būtu teikt - var izmantot.

Ja lielākā daļa vērtību sākas ar "lv", tad izmantojot indeksu būs tikai lēnāk.

 

Gints Plivna

http://datubazes.wordpress.com/

[Kavacky]

Drukas kļūda; tā arī biju domājis, paldies par labojumu!

[codez]

Ja lielākā daļa vērtību sākas ar "lv", tad izmantojot indeksu būs tikai lēnāk.

 

Tā jau gan nebūs. Ja teiksim pirmās 100 000 vērtības sāksies ar en un nākamās 9 900 000 ar lv (lielākā daļa - 99%), tad, teiksim, selektojot ar LIMIT 10, bez indeksa nāksiesi izskanēt 100 010 ierakstus, kamēr ar indeksu, nedaudz paskraidot pa indeksa koku 10 ierakstus (krietni, krietni ātrāk). Pietam vēl lielāka indeksa nozīme būs, kad pie limita parādīsies arī offsets.

Edited September 26, 2011 by codez

[Gints Plivna]

Nu runājot par datubāzēm pirmie un pēdējie ieraksti vispār ir tāds ļoti strīdīgs un nestabils jēdziens. Vienkāršākajā gadījumā, kad tabula ir 1 fails, kas atrodas parastā failu sistēmā un to pēc kārtas lasa cauri, tad tas tā varētu būt.

OK es neesmu tik smalki iedziļinājies kā MySQLs fiziski glabā ierakstus (pie tam, cik saprotu, katrai enginei tas var būt savādāk), bet man ir izveidojusies ļoti stingra pārliecība - nekad un nekādā merā nepaļauties uz to, ka DB eksistē kaut kāda predefinēta ierakstu kārtība. Pat, ja šodienas MySQL implementācijā tāda ir, nekur nav teikts, ka tā būs vienmēr un ka vienmēr ieraksti tiks lasīti kaut kādā vienā kārtībā.

OK runājot par Tevis doto piemēru, jā šajā gadījumā indekss noteikti varētu palīdzēt, bet šai gadījumā mēs gribam atlasīt tikai vienu mazu daļiņu no visiem lv ierakstiem un, protams, vispārīgi manā augšminētajā izteikumā ir stingri par maz nosacījumu, lai to varētu tā pa taisno pielietot visos gadījumos :)

 

Gints Plivna

http://datubazes.wordpress.com/

Edited September 27, 2011 by Gints Plivna