Ecco come progetterei il database:
Visualizzazione di DB Designer Fork
Il i18n la tabella contiene solo una PK, in modo che qualsiasi tabella debba semplicemente fare riferimento a questa PK per internazionalizzare un campo. La tabella translation è quindi incaricato di collegare questo ID generico con l'elenco corretto delle traduzioni.
locale.id_locale è un VARCHAR(5) per gestire entrambi en e en_US Sintassi ISO
.
currency.id_currency è un CHAR(3) per gestire la sintassi ISO 4217
.
Puoi trovare due esempi:page e newsletter . Entrambi gestiti dall'amministratore le entità devono internazionalizzare i loro campi, rispettivamente title/description e subject/content .
Ecco una query di esempio:
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
Si noti che questo è un modello di dati normalizzato. Se hai un set di dati enorme, forse potresti pensare a denormalizzarlo per ottimizzare le tue query. Puoi anche giocare con gli indici per migliorare le prestazioni delle query (in alcuni DB, le chiavi esterne vengono indicizzate automaticamente, ad es. MySQL/InnoDB ).
