daudzvalodu atbalsts identiskam saturam

[hmnc]

Sveiki,

nevaru tikt skaidrībā, kā labāk realizēt daudzvalodu atbalstu saturam, kurš visās valodās ir identisks (piemēram tabula ar cipariem un 'title' lauku.. cipari visās valodās identiski)

man ir 3 varianti, no kuriem 2 ir reāli stulbi un viens pietiekami čakarīgs:

1. (lame)

vnk tabulā mest klāt piemēram title_lv, title_ru, title_en... fleksibilitāte = 0, valodas ir ierobežotas (grūtības pielikt piemēram vēl 5), problēmas ar lauku skaitu (ja tev ir daudz tulkojamo lauku - title, description, text, ... bla bla bla..) - katram taisīt savu valodu lauku - pašnāvība

2. (json)

tajā pašā title laukā (un visos citos) metam iekšā json vai serializētu masīvu ar visām valodām. datubāžu programmētājiem šajā brīdī izkrīt mati... iedomāties to visu datu varzu vienā laukā ir grūti... atrast pēc lauka nav iespējams (ir, bet čakars), datu inserts ir sarežģīts, update ķēpīgs...

3. (multitable)

vienīgais variants, ko esmu pielietojis praksē (vēl json nedaudz). 2 tabulas - pirmajā dzenam datus, kas visās valodās ir vienādi, otrajā visus tekstus, savienojam tabulas ar pirmās tabulas id un 'language' parametru.. valodu skaits neierobežots un performanci tas īpaši nebremzē (indeksi rulz). neliela ķēpa ar ievadi/izvadi (defaulto valodu switch, etc), bet tā diezgan tīrs variants. BET - kad tādas multilanguage tabulas ar datiem ir 10... tad tev vajag pretī 10 valodu tabulas - katram savu... sākās problēmas..

 

nu lūk, tad man jautājums gudrākiem tautiešiem - vai reāli ir vēl kāds variants, līdz kuram man prāts nevelk? vai arī kāda modifikācija no šiem?

 

paldies jau iepriekš

[mounkuls]

....kad tādas multilanguage tabulas ar datiem ir 10... tad tev vajag pretī 10 valodu tabulas - katram savu... sākās problēmas..

Kāpēc tad vajag pretī 10 valodu tabulas?

 

[vienadie_dati_x](laikam tādas būs vairākas)

id | saturs | default_lng | etc

 

[valodas](visu vienā)

valodas_id | satura_id | tabulas_id | tulkojums | etc_par_vienadie_dati_x.id

 

vai ar vairākām valodu tabulām (itkā vieglāk pievienot jaunu valodu)

[valoda_y]

satura_id | tabulas_id | tulkojums | etc_par_vienadie_dati_x.id

 

Bet ne jau 10 datu tabulām pretī taisīt katrai vēl 10 valodu tabulas, man tas liekas par traku.

Lai gan, kas zina, ja to datu apjoms ir milzīgs....

 

Nu tās manas domas, bet es jau nav nekāds pro

[Kaklz]

Vai nu nesapratu, ko tu centies panākt, bet kur ir problēma ar

id | lang | key | translation

 

mehānismu?

[ohmygod]

Kaklz +1

[Aleksejs]

Nu, visumā glabājot vienā tabulā to visu ir ātruma ieguvums (pieņemsim, ka jāatlasa 4 lauki: id, nosaukums, apraksts, saturs), jo:

 

SELECT id, nosaukums_lv AS nosaukums, apraksts_lv AS apraksts, saturs_lv AS saturs FROM produkti WHERE id = 8

manuprāt izpildās ātrāk nekā:

SELECT p.id AS id, t1.translation AS nosaukums, t2.translation AS apraksts, t3.translation AS saturs
  FROM produkti AS p
  LEFT JOIN tulkojumi AS t1 ON p.id = t1.id
  LEFT JOIN tulkojumi AS t2 ON p.id = t2.id
  LEFT JOIN tulkojumi AS t3 ON p.id = t3.id
  WHERE p.id = 8 AND t1.tabulas_id = 7 AND t2.tabulas_id = 7 AND t3.tabulas_id = 7 AND
     t1.lang = 1 AND t2.lang = 1 AND t3.lang = 1
     t1.lauka_id = 1 AND t2.lauka_id = 2 AND t3.lauka_id = 3

Piezīmes: Pieņemsim, ka produktu tabulai ir tabulas_id = 7, latviešu valodai lang = 1 un attiecīgi laukiem - nosaukums, apraksts, saturs - ir id: "1,2,3".

 

Līdz ar to jāizvērtē, kādas lietas ir svarīgākas.

[hmnc]

Kaklz risinājums ir vistuvākais patiesībai, bet ja summārais tabulu ierakstu skaits ir tuvu 50`000. sanāk 4 valodas, kopā tulkojamie lauki ~10. kopā sanāk nevāja tabula ar 2milj ierakstiem. itkā nav tik kosmiski daudz, bet tomēr...

[hmnc]

sapratu par ko aleksejs runā.... neesmu vēl pamodies.. tā ir reāla problēma (ar Alekseja piemēru)...

Edited July 14, 2009 by hmnc

[Aleksejs]

Nu vēl viens veids, kas varētu būt kā kompromiss...

Pieņemsim atkal, ka vajag tabulu produkti:

Nemainīgās lietas:

id,artikuls,ean_kods,cena

Tulkojamās lietas:

nosaukums,apraksts,saturs

 

Tad varam izveidot tabulu:

produkti_stat ar laukiem:

id,artikuls,ean_kods,cena

 

un attiecīgi tik daudz, cik nepieciešams tabulas:

produkti_XX (kur XX=lv,ru,en,de,jp,kr,cn ...) ar laukiem:

product_id,nosaukums,apraksts,saturs

 

Tādā gadījumā atlases SQLs būs vienkāršāks un gana ātrs, nekā vienas tulkojamās tabulas gadījumā:

SELECT * FROM produkti_stat
  LEFT JOIN produkti_lv ON produkti_stat.id = produkti_lv.product_id
  WHERE produkti_stat.id = 8

 

Plusi tādi, ka:

- nav simtiem lauku un produkti_XX tiek veidoti pēc vienota šablona.

- vieta uz diska tieši saistīta ar to, cik daudz iztulkots - netiek veidotas tukšās šūnas... Laikam varchar,text utt. gadījumā šis nav īpašs arguments, jo tie tāpat aizņem minimālu vietu, ja nav aizpildīti.

[hmnc]

nu tas ir tas mans 3 variants, vienīgi tabula ir unificēta un vienkārši tiek pielikts klāt 'language' parametrs - nav jāizmanto vairākas tabulas vienai produktu tabulai

[Aleksejs]

Ā, nu ja :) Kaut kā aizmirsu, ko rakstīji sākumā. ;)

 

Vēl viena ideja... Atstājam unificētu tabulu translations, bet paredzam (galu galā mēs taču zinam, kādas būs tabulas un cik tajās būs tulkojamo lauku) maksimālo tulkojamo lauku skaitu, kāds pieejams jebkurā no tabulām (pieņemsim, ka pēc mūsu projekta analīzes esam sapratuši, ka būs ne vairāk par 5 tulkojamajiem laukiem). Un tad aplikācijas loģikā iestrādājam (ja nu kas, varam izveidot Viewus un procedūras, kas to izpilda, lai pašā PHP kodā tas nav jādefinē), ka tabulai produkti laukā lauks1 galabājas nosaukums, lauks2 glabājas apraksts, lauks3 glabājas saturs; savukārt tabulai piegadataji (nu, piemēram) laukā lauks1 glabājas adrese, lauks2 glabājas uzņēmuma nodarbošanās apraksts utt.

 

tabula tulkojumi:

tabulas_id,ieraksta_id,valodas_id

lauks1,

lauks2,

lauks3,

lauks4,

lauks5.

 

tālāk atlasi veicam tāpat kā 3 variantā un esam ieguvuši to, ka tulkojumi glabājas vienā +- unificētā tabulā. Ja nu izrādās, ka ar tiem 5 laukiem nepietiek, tad attiecīgi jāliek klāt kārtējais lauks, kura pielikšanai nevajadzētu ietekmēt neko. Vieta gan nedaudz tiek nelietderīgi izmantota, taču zinot, ka tukšs text lauks tāpat īpaši daudz neaizņem, šāda izšķērdība varētu būt attaisnojama.

 

Skatoties no Datu uzbūves viedokļa - šis nav elegants risinājums, taču iegūta ir ātrdarbība.

[hmnc]

sakarīgs variants, vienīgi katrai tabulai bik ķēpa ar insert/update.

ko db eksperti saka par tukšiem text laukiem?

[Aleksejs]

Nu, ķēpa ar insert/update ne lielāka kā jebkurā citā dalītajā variantā.

[Klez]

--
-- Table structure for table `jaunumi`
--

CREATE TABLE IF NOT EXISTS `jaunumi` (
 `id` int(3) NOT NULL auto_increment,
 `datums` date NOT NULL,
 PRIMARY KEY  (`id`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 AUTO_INCREMENT=3 ;

--
-- Dumping data for table `jaunumi`
--

INSERT INTO `jaunumi` (`id`, `datums`) VALUES
(1, '2009-07-14'),
(2, '2009-07-13');

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

--
-- Table structure for table `tulkojumi`
--

CREATE TABLE IF NOT EXISTS `tulkojumi` (
 `id` int(4) NOT NULL auto_increment,
 `tulkojums` text NOT NULL,
 `lang_id` int(4) NOT NULL,
 `object_id` int(4) NOT NULL,
 `table_id` int(4) NOT NULL,
 PRIMARY KEY  (`id`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 AUTO_INCREMENT=3 ;

--
-- Dumping data for table `tulkojumi`
--

INSERT INTO `tulkojumi` (`id`, `tulkojums`, `lang_id`, `object_id`, `table_id`) VALUES
(1, 'Teksts LV', 1, 1, 1),
(2, 'Teksts RU', 2, 1, 1);


SELECT jaunumi.datums, tulkojumi.tulkojums FROM `jaunumi` 
JOIN tulkojumi ON tulkojumi.object_id = jaunumi.id AND tulkojumi.table_id = 1 AND tulkojumi.lang_id = 1
ORDER BY jaunumi.datums ASC
Rezultāts: 
datums 	tulkojums
2009-07-14 	Teksts LV
vai
SELECT jaunumi.datums, tulkojumi.tulkojums FROM `jaunumi` 
JOIN tulkojumi ON tulkojumi.object_id = jaunumi.id AND tulkojumi.table_id = 1 AND tulkojumi.lang_id IN (1,2)
ORDER BY jaunumi.datums ASC
rezultāts:
datums 	tulkojums
2009-07-14 	Teksts LV
2009-07-14 	Teksts RU

 

varūt ka tā var .. ? vienīgi varbūt ka table_id vajag kā tekstu .. piem jaunumi, nevis ciparu, vieglāk saprast ..

Edited July 14, 2009 by Klez

[hmnc]

Klez - izlasi visus postus, šis jau ir aprunāts variants :)

[Klez]

es izlasīju ... bet šim nav ne vainas. manuprāt ... viņš gandrīz tāds pats kā tavējais ..