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

Question

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

Muszę stworzyć wielojęzyczny model DB dla aplikacji webowej.

Jedna wątpliwość, że mam za każdym razem myślę, jak to zrobić jest jak mogę rozwiązać mając wiele tłumaczeń dla pola. Przykład przypadku.

Tabela poziomów językowych, którą administratorzy mogą edytować z zaplecza, może zawierać wiele elementów, takich jak: basic, advance, fluent, mattern... W niedalekiej przyszłości prawdopodobnie będzie to jeszcze jeden typ. Administrator przechodzi do zaplecza i dodaje nowy poziom, posortuje go w odpowiedniej pozycji.. ale jak obsługiwać wszystkie tłumaczenia dla użytkowników końcowych?

Innym problemem z internacjonalizacją bazy danych jest to, że prawdopodobnie dla badań Użytkowników mogą się różnić od USA do WIELKIEJ BRYTANII do DE... w każdym kraju będą miały swój poziom (że prawdopodobnie będzie to odpowiednik innego, ale w końcu inny). A co z rachunkami?

Jak to modelować na dużą skalę?

31

mysql database database-design internationalization multilingual

Author: M4N, 2012-05-22

Source

2 answers

Kilka poprzednich pytań na ten temat:

Niektóre przydatne zewnętrzne zasoby:

Najlepszym rozwiązaniem jest często tworzenie nowej tabeli dla każdej istniejącej tabeli, do której przenoszone są elementy tekstowe; PK nowej tabeli jest PK starej tabeli wraz z językiem.

W Twoim przypadku:

Tabela dla języka poziomy, które administratorzy mogą edytować z zaplecza, mogą mieć wiele elementów, takich jak: podstawowy, zaawansowany, płynny, mattern... W niedalekiej przyszłości prawdopodobnie będzie to jeszcze jeden typ. Administrator przechodzi do zaplecza i dodaje nowy poziom, posortuje go we właściwej pozycji.. ale jak obsługiwać wszystkie tłumaczenia dla użytkowników końcowych?

Twoja istniejąca tabela prawdopodobnie wygląda mniej więcej tak:

+----+-------+---------+
| id | price | type    |
+----+-------+---------+
|  1 |   299 | basic   |
|  2 |   299 | advance |
|  3 |   399 | fluent  |
|  4 |     0 | mattern |
+----+-------+---------+

Następnie staje się dwie tabele:

+----+-------+   +----+------+-------------+
| id | price |   | id | lang | type        |
+----+-------+   +----+------+-------------+
|  1 |   299 |   |  1 | en   | basic       |
|  2 |   299 |   |  2 | en   | advance     |
|  3 |   399 |   |  3 | en   | fluent      |
|  4 |     0 |   |  4 | en   | mattern     |
+----+-------+   |  1 | fr   | élémentaire |
                 |  2 | fr   | avance      |
                 |  3 | fr   | couramment  |
                 :    :      :             :
                 +----+------+-------------+

Kolejny problem z internationalitzation bazy danych jest to, że prawdopodobnie dla badań użytkownika może różnić się od USA do WIELKIEJ BRYTANII do DE... w każdym kraju będą miały swój poziom (że prawdopodobnie będzie to odpowiednik innego, ale w końcu inny). A co z rachunkami?

Wszystkie lokalizacje mogą wystąpić dzięki podobnemu podejściu. Zamiast tylko przenosić pola tekstowe do nowej tabeli, możesz przenosić dowolne pola z możliwością lokalizacji - tylko te, które są wspólne dla wszystkich lokalizacji, pozostaną w oryginale stolik.

28

Author: eggyal,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 11:46:58

score 52 · Accepted Answer

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

Model danych

Wizualizacja przez DB Designer Fork

Tabela i18n zawiera tylko PK, więc każda tabela musi odwołać się do tego PK, aby umiędzynarodowić pole. Tabela translation jest następnie odpowiedzialna za powiązanie tego generycznego identyfikatora z prawidłową listą tłumaczeń.

locale.id_locale jest VARCHAR(5) do zarządzania obiema en i en_US składnia ISO .

currency.id_currency jest CHAR(3) do Zarządzaj składnią ISO 4217 .

Można znaleźć dwa przykłady: page i newsletter. Oba te zarządzane przez admina entity muszą umiędzynarodowić 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że mógłbyś pomyśleć o denormalizowaniu go , aby zoptymalizować swoje zapytania. Możesz także grać z indeksami, aby poprawić wydajność zapytań (w niektórych DB klucze obce są automatycznie indeksowane, np. MySQL/InnoDB).