Databasemodellering til internationale og flersprogede formål

Her er den måde, jeg ville designe databasen på:

i18n tabel indeholder kun en PK, så enhver tabel skal blot henvise til denne PK for at internationalisere et felt. Tabellen translation er derefter ansvarlig for at forbinde dette generiske ID med den korrekte liste over oversættelser.

locale.id_locale er en VARCHAR(5) for at administrere begge en og en_US ISO-syntakser .

currency.id_currency er en CHAR(3) for at administrere ISO 4217-syntaksen .

Du kan finde to eksempler:page og newsletter . Begge disse admin-administrerede enheder skal internationalisere deres felter, henholdsvis title/description og subject/content .

Her er et eksempel på en forespørgsel:

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

Bemærk, at dette er en normaliseret datamodel. Hvis du har et stort datasæt, kunne du måske overveje at denormalisere det for at optimere dine forespørgsler. Du kan også lege med indekser for at forbedre forespørgselsydeevnen (i nogle DB indekseres fremmednøgler automatisk, f.eks. MySQL/InnoDB ).