Voici comment je concevrais la base de données :
Visualisation par DB Designer Fork
Le i18n table ne contient qu'un PK, de sorte que n'importe quelle table n'a qu'à référencer ce PK pour internationaliser un champ. Le tableau translation se charge ensuite de lier cet identifiant générique à la bonne liste de traductions.
locale.id_locale est un VARCHAR(5) pour gérer les deux en et en_US Syntaxes ISO
.
currency.id_currency est un CHAR(3) pour gérer la syntaxe ISO 4217
.
Vous pouvez trouver deux exemples :page et newsletter . Ces deux éléments sont gérés par l'administrateur les entités doivent internationaliser leurs champs, respectivement title/description et subject/content .
Voici un exemple de requête :
select
t_subject.tx_translation as subject,
t_content.tx_translation as content
from newsletter n
-- join for subject
inner join translation t_subject
on t_subject.id_i18n = n.i18n_subject
-- join for content
inner join translation t_content
on t_content.id_i18n = n.i18n_content
inner join locale l
-- condition for subject
on l.id_locale = t_subject.id_locale
-- condition for content
and l.id_locale = t_content.id_locale
-- locale condition
where l.id_locale = 'en_GB'
-- other conditions
and n.id_newsletter = 1
Notez qu'il s'agit d'un modèle de données normalisé. Si vous avez un énorme ensemble de données, vous pourriez peut-être penser à le dénormaliser pour optimiser vos requêtes. Vous pouvez également jouer avec les index pour améliorer les performances des requêtes (dans certaines bases de données, les clés étrangères sont automatiquement indexées, par exemple MySQL/InnoDB ).
