Weblabor

Sziasztok!

Saját keretrendszeremhez szeretnék többnyelvű adatok tárolását elegánsan megoldó megoldást fejleszteni. Mindegyik megfejtés valamilyen kompromisszumot jelentene, az eddigi búvárkodásom alapján. Szerintetek melyik módszernek legjobb a hatékonyság / teljesítmény aránya?
Több egymásnak ellentmondó igényem van. :)
Minél kevésbé bonyolítson minden lekérdezést pusztán az a tény, hogy több nyelven tárolok adatokat.
A lehető legtöbb dolog történjen implicit, hogy kisebb legyen a hibalehetőség, és javuljon az áttekinthetőség (pl. lekérdezések automatius újraírása révén kivitelezve)
Ne legyen nagyságrenddel lassabb tízmillós rekordszám mellett sem a nyelvesítetlen megoldásnál. Ezek a fontosabbak.

• Az adattáblában egy nyelv mező alapján kérjük le rekord egy bizonyos nyelvű változatát.
  előny: minimálisan bonyolítja a lekérdezéseket (egy AND lang='hun' szerű feltétellel)
  hátrány: sok helyen a legtöbb mezőt nem kéne nyelvesíteni (mindenféle számértékek, flagek), kicsit favágó módszer, bár több helyen használják (persze a többi módszernek is mind van valóságalapja).
  
  
• Az táblák kettéoszlanak egy általános infókat tartalmazó táblára (id, timestamp, stb)
  és egy table_text társtáblára, ahol a táblának a nyelvesítendő mezői szerepelnek kigyűjtve. Ebből aztán egy joinnal megkapjuk a kért mező fordítását
  előny: csak a szükséges mezőket tároljuk, nincs egy nagy mamuttábla minden szöveg fordításával, azaz talán gyorsabb is.
  hátrány: Egyszerű lekérdezésekből is join-ok lesznek. Majdnem minden táblából kettő lesz. Nem rossz módszer, de furcsa a logika, hogy ilyen dimenziót viszünk a táblákra bontásba. Mintha adattípus szerint csinálnék táblákat és az adatok hovatartozását egy "tábla" mező alapján követném vissza. Persze ez túlzás.
  
  
• az adat táblájában semmi nem utal a nyelvre, viszont egy tranlation táblát készítek ilyen mezőkkel:
  [table], [col], [id], [language], [text]
  Ebből aztán vagy sql-ből, vagy akár php-ból egy második selecttel, vagy a lekérdezés implicit átírásával, kérjük le a fordítás táblából az adatot.
  előny: Minden fordított szöveg egy helyen, ha nincs szükség a nyelvekre, akkor egyszerűen ignorálható, ha jól valósítom a meg a lekérésüket, akkor tiszta ügy.
  hátrány: 2 szimpla lekérdézés, lehet hogy lassabb, mint egy join-os, a lekérdezés php-s átírása is jár valamennyi overheaddel. Egy gigászi tábla, ahol ráadásul akár többféle hosszúságú szöveget is kell tárolni (varchar, text). Aggályos.
  
  
• Az előző módszer egy változata, hogy nem használok ennyi metaadatot a translation táblában a rekord azonosítására, hanem közvetlenül az adott szöveg eredetije lesz az "id"-je a fordított változatoknak. Esetleg ha gond az, hogy akár több oldalas is lehet egy szöveg, akkor ebből egy md5 vagy sha hash-t generálnék, és ez lenne a nyelvi adat id-je. (nem nagy az esély, hogy két egyforma legyen, de még ez is kivédhető)
  előny: Egyetlen adat azonosítja a rekordot, áttekinthető, kevesebb php-beli logikát kell programozni mellé. Egyszerűen kihagyható a nyelvesítés szükségtelensége esetén.
  hátrány: Mammuttábla, a plusz kód is lassít, a plusz lekérdezés is lassíthat, továbbá mivel a fordítandó szöveg mérete elég változatos lehet ezért egyféle pl. text tipusu mező nem tél gazdaságos/hatékony, ha többféle adathordozó mezőt hozok létre, akkor már a tipust is le kell kérdeznem, és aszerint is szűrni, belegondolni se jó.
  

Leginkább azt nem tudom megítélni, hogy mi mennyit nyom a latban. Két egyszerű tiszta select lehet hogy gyorsabb mint egy join, de legalábbis nem jelentősen lassabb. A több, de egyszerűbb lekérdezés adta áttekinthetőség révén nyert hatékonyság sem mellékes szempont, kis overhead legyelhető lenne, ha nyernénk valamit a vámon.

Eleve nem értem miért nem implmentáltak erre egy out-of-the-box megoldást az adatbáziskezelők,
kicsit olyan ez mintha idegenkulcs-kényszer kezelését kellene emulálnom php-ból.
Vannak még gondolataim, de majd a kommentekben megbeszéljük.

Köszönöm előre is gondolataitokat!