Esta es la forma en que diseñaría la base de datos:
Visualización por DB Designer Fork
El i18n la tabla solo contiene una PK, por lo que cualquier tabla solo tiene que hacer referencia a esta PK para internacionalizar un campo. La tabla translation luego se encarga de vincular esta identificación genérica con la lista correcta de traducciones.
locale.id_locale es un VARCHAR(5) para administrar ambos en y en_US Sintaxis ISO
.
currency.id_currency es un CHAR(3) para gestionar la sintaxis ISO 4217
.
Puedes encontrar dos ejemplos:page y newsletter . Ambos gestionados por el administrador las entidades necesitan internacionalizar sus campos, respectivamente title/description y subject/content .
Aquí hay una consulta de ejemplo:
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
Tenga en cuenta que este es un modelo de datos normalizados. Si tiene un gran conjunto de datos, tal vez podría pensar en desnormalizarlo para optimizar sus consultas. También puede jugar con índices para mejorar el rendimiento de las consultas (en algunas bases de datos, las claves externas se indexan automáticamente, por ejemplo, MySQL/InnoDB ).
