
Here is the way I would design the database:
Visualization byDB Designer
Fork
The
i18ntable only contains a PK, so that any table just has to reference
this PK to internationalize a field. The table
translationis then in charge
of linking this generic ID with the correct list of translations.
locale.id_localeis a
VARCHAr(5)to manage both of
enand
en_USISO
syntaxes.
currency.id_currencyis a
CHAr(3)to manage the ISO 4217
syntax.
You can find two examples:
pageand
newsletter. Both of these admin-
managed entites need to internationalize their fields, respectively
title/descriptionand
subject/content.
Here is an example query:
select t_subject.tx_translation as subject, t_content.tx_translation as contentfrom newsletter n-- join for subjectinner join translation t_subject on t_subject.id_i18n = n.i18n_subject-- join for contentinner join translation t_content on t_content.id_i18n = n.i18n_contentinner 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 conditionwhere l.id_locale = 'en_GB' -- other conditions and n.id_newsletter = 1
Note that this is a normalized data model. If you have a huge dataset, maybe
you could think about denormalizing
it to optimize your queries.
You can also play with indexes to improve the queries performance (in some DB,
foreign keys are automatically indexed, e.g.
MySQL/InnoDB).
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)