[php] Database model met verschillende talen

[RSD]

Het zal ongetwijfeld al wel eens behandeld zijn, maar ik kom er niet uit. Ook na het zoeken op bepaalde termen. Misschien zoek ik verkeerd, maar daar kom ik dan wel achter. Nu is het zo. Ik heb een grote database met allemaal titels, omschrijvingen, images en rubrieken. Nu kan één product in meerdere rubrieken zitten. Deze titels, omschrijvingen en rubrieken zijn ook beschikbaar in andere talen. Dus in het Nederlands, Engels, Duits etc... Nu moet elke taal zijn eigen website krijgen maar wel gebruik maken van hetzelfde plaatje. Hoe kan ik nu het beste de database(s) opzetten. Kan ik het beste elke taal zijn eigen database geven. Dus iets als:

product
- id
- image

product_nl
- productid
- title
- desc

product_en
- productid
- title
- desc

tag
- id

tag_nl
- tag_id
- title

tag_en
- tag_id
- title

producttag
- product_id
- tag_id

of kan ik beter het volgende doen:

product
- id
- image
- title_nl
- desc_nl
- title_en
- desc_en

tag
- id
- title_nl
- title_en

producttag
- product_id
- tag_id

Welke optie is het beste of zijn er nog betere opties. Het gaat om ongeveer 8 verschillende talen

[Napo]

Of je maakt een apart tabel waarin je per product meerdere entries maakt zoiets dus

tabel product_desc
-prodct_id
-language
-description

Dan zou je in theorie later makkelijk kunnen uitbreiden naar nog een extra taal
Zelf zou ik het gehele nl en en uit de tabel/kolomnamen proberen te houden.

[ Voor 14% gewijzigd door Napo op 03-03-2012 13:23 ]

[kwaakvaak_v2]

Inderdaad, de taal is een eigenschap van een object, dus hoort niet imho niet in een tabel of kolom als pre/post-fix thuis.

En voor de rest, wat Paul in Twijfels over opzet database zegt, een entity-relationship model klinkt wel als een mogelijke oplossing in deze.

[RSD]

Maar de verschillende teksten komen wel op aparte sites te staan. Dus is het dan niet handiger om per site een eigen database te gebruiken?

[T-MOB]

Ik doe het eigenlijk altijd zo:

lang
- tag //iso3166 code
- name

entity_x
- id
- prop_a
- prop_b

entity_x_content
- id  --> entity_x.id
- lang  --> lang.tag
- prop_c
- prop_d

Dus in de entitiy_x tabel staan alle eigenschappen die voor alle talen gelden, prijzen, coordinaten, plaatjes, etc. Entity_x_content bevat alle content die taalafhankelijk is. Eén join is dan genoeg om al je properties in een taal (en alleen in die taal) op te halen.

RSD schreef op zaterdag 03 maart 2012 @ 13:55:
Maar de verschillende teksten komen wel op aparte sites te staan. Dus is het dan niet handiger om per site een eigen database te gebruiken?

Hoe je het gebruikt maakt niet uit. Het gaat er om welke data logisch gezien bij elkaar hoort. In het geval van productdata beschrijven de vertalingen allemaal dezelfde producten. Dan kun je dat beter ook in een database bij elkaar opslaan.
Wat je in geval van meerdere sites wel kunt overwegen is om per site een aparte database aan te houden met de data specifiek voor die site, bijvoorbeeld sessies of site-specieke banners, of... Op de verschillende sites connect je dan met 2 databases: 1 connectie met de sitespecieke data en 1 connectie met de productdata. Maar goed, dit is eigenlijk alleen zinnig als de sites ook echt verschillend moeten zijn. Ik heb dat nog nooit meegemaakt, in mijn ervaring zijn meertalige site eigenlijk altijd min-of-meer hetzelfde. Dus gaat alles bij mij in dezelfde database.

[ Voor 53% gewijzigd door T-MOB op 03-03-2012 14:18 ]

[RSD]

En wat nu als één taal bijvoorbeeld 2 miljoen producten bevat. Is het dan ook nog wel handig om het zo te doen?

[The Eagle]

Laat ik nou toevallig meerder multi language systemen beheren en precies weten hoe dit zit

OK, here goes:

Allereerst: In je datatabellen heb je eigenlijk niet eens iets te zoeken. Het enige dat je hoeft op te nemen is een extra veld, genaamd "language_related" oid. Dat, icm de taal waarin de website benaderd wordt, is de trigger om een bepaalde taal te displayen.
Vervolgens maak je naast je "normale" PRODUCT tabel, een tabel genaamd PRODUCT_LANG. In de PRODUCT tabel zit je standaard taal, in de PRODUCT_LANG tabel de gegevens die getoond moeten worden als je in een andere taal werkt. In principe zijn het de zelfde tabellen, echter met een veld LANGUAGE_CD extra.

Op basis van de language_related en de vlag die bij het inloggen gezet wordt, kun je zo de boel afvragen en de juiste descs tonen.

Doe je zo dingen dubbel? Ja, in principe wel. Echter geeft het je de mogelijkheid om in eerste instantie de hele boel in een basistaal te zetten en in te voeren, en vervolgens de boel te vertalen. Daarnaast kun je ook makkelijk een andere taal toevoegen mocht dat achteraf nodig zijn, zonder iets aan te hoeven passen
Mocht je op een gegeven moment ook in frankrijk willen verkopen, dan hoef je niet je hele systeem een makeover te geven
Bovendien een stuk makkelijker te onderhouden, mochten er descrs veranderen. De basis blijft namelijk altijd gelijk, alleen de specifieke landvertalingen veranderen soms
Tot slot: aangezien de basislanguage vermoedelijk vaker gebruikt wordt als de rest, heb je de mogelijkheid om zoekacties voor de basistaal sowieso te optimaliseren, en voor andere talen mondjesmaat of per taal. Zoeken wordt daar ook sneller door

Overigens zit het bij die systemen die ik beheer nog iets gecompliceerder, maar dan zou ik je in de wondere wereld van PeopleSoft moeten introduceren, en dat doe ik ff lekker niet

[ Voor 91% gewijzigd door The Eagle op 03-03-2012 14:29 ]

[T-MOB]

RSD schreef op zaterdag 03 maart 2012 @ 14:17:
En wat nu als één taal bijvoorbeeld 2 miljoen producten bevat. Is het dan ook nog wel handig om het zo te doen?

Waarom niet? Je moet het toch ergens opslaan. (Ik dacht trouwens dat de producten in alle talen beschikbaar moesten zijn). Maar goed, een paar miljoen records gaat niet echt voor problemen zorgen.

[kwaakvaak_v2]

Andere optie is om het wat 'slimmer' te maken, en iets als XLIFF te gebruiken.

(zie bijvoorbeeld hoe Symfony2 dat implementeerd)

Voordeel daarmee is dat dingen als enkelvoud, meervoud en samengestelde strings ook af te vangen is. En XLIFF is net als po een industriestandaard. Je vertaling zit dus pas op de presentatie laag. Het nadeel is dat je een los vertaal systeem hebt maar daar zijn ook wel tools voor te vinden.

[efan]

of via google api: http://code.google.com/intl/nl/apis/language/

[kwaakvaak_v2]

Ja automatische vertalingen, dan krijg je tenminste van die geweldige vertalingen als in de app-store

[RSD]

Het gaat me er niet om hoe ik een website het beste vertaal, maar hoe ik de verschillende talen het beste kan opslaan in een database zodat deze snel opgehaald kunnen worden. Zelf dacht ik dat als ik zeg maar 2 miljoen records heb in 1 taal en in 1 tabel, dat het dan beter is om de talen in aparte databases te doen in verband met de grootte van de database, maar dat maakt niet zo heel erg veel uit dus.

[DataGhost]

Eh, dat maakt zeker wel uit. Op het moment dat je correct gebruik maakt van indexen maakt het niet meer uit Anders is trouwens sowieso het aantal producten op zichzelf al een bottleneck.

[ Voor 26% gewijzigd door DataGhost op 03-03-2012 14:45 ]

[RSD]

Jah dat doe ik wel denk ik... hoop ik ;-)

[Verwijderd]

DataGhost schreef op zaterdag 03 maart 2012 @ 14:45:
Eh, dat maakt zeker wel uit. Op het moment dat je correct gebruik maakt van indexen maakt het niet meer uit Anders is trouwens sowieso het aantal producten op zichzelf al een bottleneck.

Inderdaad. Lees ff een tutorial over indexen en zorg er vervolgens voor dat je het language ID in je multi-column index opneemt. Performance zal waanzinnig goed zijn.

Dus:

product:
- id
- image

product_desc:
-product_id
-language
-title
-description

De index op product.id en ook nog één op product_id+language. Ik zou language dan gewoon enum() doen. Is in dit geval onderwater toch een unsigned smallint, dus lekker snel, compact en makkelijk te lezen.

[ Voor 25% gewijzigd door Verwijderd op 04-03-2012 17:20 ]

[The Eagle]

Zet dan ook een index op language. Mocht je dan iets te onderhouden hebben of op moeten zoeken, kun je dat ook meteen op taal doen

[Verwijderd]

Verwijderd schreef op zondag 04 maart 2012 @ 17:14:
De index op product.id en ook nog één op product_id+language. Ik zou language dan gewoon enum() doen. Is in dit geval onderwater toch een unsigned smallint, dus lekker snel, compact en makkelijk te lezen.

Waarom zou je van language een enum maken? Dan heb je toch weer een stuk minder beheer over je talen.. Minder makkelijk te wijzigen, minder makkelijk nieuwe aan te maken. Enums zijn imho te gebruiken voor zaken die niet van naam kunnen/mogen wijzigen.

[kwaakvaak_v2]

Enums zijn imho te gebruiken voor zaken die niet van naam kunnen/mogen wijzigen.

Ik acht de kans dat morgen Frans ineens Swahili wordt ook redelijk klein ;:

[Cartman!]

Maar de kans dat je swahili wilt toevoegen als ondersteunde taal is des te groter. Dan kun je overal je enums aanpassen. Gewoon een losse tabel van maken dus en daar de primary key van gebruiken, kun je alle kanten op.

[The Eagle]

Gewoon een language code veld met VARCHAR(3) is voldoende. Da's vziw ook de internationale standaard (ja, daar zijn standaarden voor, zie Wikipedia: List of ISO 639-1 codes )

[Cartman!]

Dat is veruit de slechtste manier om dit te doen als je denkt over performance en onderhoudbaarheid.

[The Eagle]

Cartman! schreef op maandag 05 maart 2012 @ 13:41:
Dat is veruit de slechtste manier om dit te doen als je denkt over performance en onderhoudbaarheid.

Ik zou niet weten waarom. Leg eens uit?
Noot dat ik dus bedoelde dat het veld language in onderstaande tabel dus gewoon een varchar(3) veld moet zijn

product_desc:
-product_id
-language
-title
-description

[ Voor 25% gewijzigd door The Eagle op 05-03-2012 15:09 ]

[Cartman!]

Een index op int+int is sowieso sneller dan int+string, dat lijkt me logisch. En als je dan al een string(representatie) wilt gebruiken neem je een ENUM, dan gebruikt ie intern ook een int (dus sneller).

Maar als je op meerdere tabellen zo'n veld hebt zitten, gewoon FK naar een language (of locale) tabel leggen en klaar ben je.

Edit: en late reactie...maar waarom als 3 karakters je taal opslaan als er ook een standaard is voor 2 karakters?

[ Voor 15% gewijzigd door Cartman! op 06-03-2012 20:15 ]

[alienfruit]

Ik gebruik zelf gewoon zoiets:

SQL:

tabel:
...
-langPid
-language (fk naar languages tabel(id, code, name)

SELECT t1.*,
    IFNULL(t2.name, t1.name) AS name
FROM tabel AS t1
LEFT OUTER JOIN tabel AS t2 ON (t1.id=t2.langPid AND t2.language=1) 
WHERE t1.langPid=0 AND (t1.id IN (7, 2, 3, 6, 4, 5))