Aqui está a maneira como eu projetaria o banco de dados:
Visualização por DB Designer Fork
O
i18n table contém apenas um PK, de modo que qualquer tabela só precisa referenciar este PK para internacionalizar um campo. A tabela translation é então responsável por vincular esse ID genérico com a lista correta de traduções. locale.id_locale é um VARCHAR(5) para gerenciar ambos en e en_US Sintaxes ISO
. currency.id_currency é um CHAR(3) para gerenciar a sintaxe ISO 4217
. Você pode encontrar dois exemplos:
page e newsletter . Ambos gerenciados pelo administrador as entidades precisam internacionalizar seus campos, respectivamente title/description e subject/content . Aqui está um exemplo de consulta:
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
Observe que este é um modelo de dados normalizado. Se você tiver um grande conjunto de dados, talvez possa pensar em desnormalizá-lo para otimizar suas consultas. Você também pode brincar com índices para melhorar o desempenho das consultas (em alguns bancos de dados, as chaves estrangeiras são indexadas automaticamente, por exemplo, MySQL/InnoDB ).
