So würde ich die Datenbank gestalten:
Visualisierung durch DB Designer Fork
Der i18n table enthält nur einen PK, sodass jede Tabelle nur auf diesen PK verweisen muss, um ein Feld zu internationalisieren. Die Tabelle translation ist dann dafür verantwortlich, diese generische ID mit der richtigen Übersetzungsliste zu verknüpfen.
locale.id_locale ist ein VARCHAR(5) um sowohl en zu verwalten und en_US ISO-Syntax
.
currency.id_currency ist ein CHAR(3) um die ISO 4217-Syntax
zu verwalten .
Sie können zwei Beispiele finden:page und newsletter . Beides vom Administrator verwaltet Entitäten müssen ihre Felder bzw. title/description internationalisieren und subject/content .
Hier ist eine Beispielabfrage:
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
Beachten Sie, dass dies ein normalisiertes Datenmodell ist. Wenn Sie einen riesigen Datensatz haben, könnten Sie vielleicht darüber nachdenken, ihn zu denormalisieren um Ihre Abfragen zu optimieren. Sie können auch mit Indizes spielen, um die Abfrageleistung zu verbessern (in einigen DBs werden Fremdschlüssel automatisch indiziert, z. B. MySQL/InnoDB ).
