Modelowanie baz danych do celów międzynarodowych i wielojęzycznych

Oto sposób, w jaki zaprojektowałbym bazę danych:

Wizualizacja Fork projektanta DB

i18n tabela zawiera tylko PK, więc każda tabela musi tylko odwoływać się do tego PK, aby umiędzynarodowić pole. Tabela translation jest wtedy odpowiedzialny za powiązanie tego ogólnego identyfikatora z poprawną listą tłumaczeń.

locale.id_locale jest VARCHAR(5) zarządzać obydwoma en i en_US Składnie ISO .

currency.id_currency to CHAR(3) do zarządzania składni ISO 4217 .

Możesz znaleźć dwa przykłady:page i newsletter . Oba te zarządzane przez administratorów podmioty muszą internacjonalizować swoje pola, odpowiednio title/description i subject/content .

Oto przykładowe zapytanie:

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

Zauważ, że jest to znormalizowany model danych. Jeśli masz ogromny zbiór danych, możesz pomyśleć o denormalizacji aby zoptymalizować Twoje zapytania. Możesz także bawić się indeksami, aby poprawić wydajność zapytań (w niektórych DB klucze obce są automatycznie indeksowane, np. MySQL/InnoDB ).