Jakie są najlepsze praktyki w projektowaniu wielojęzycznych baz danych? [zamknięte]

Jaki jest najlepszy sposób na stworzenie wielojęzycznej bazy danych? Aby utworzyć zlokalizowaną tabelę dla każdej tabeli, projektowanie i zadawanie zapytań jest skomplikowane, w innym przypadku dodanie kolumny dla każdego języka jest proste, ale nie dynamiczne, pomóż mi zrozumieć, jaki jest najlepszy wybór dla aplikacji korporacyjnych

Author: Dan J, 2009-05-30

5 answers

Tworzymy dwie tabele dla każdego wielojęzycznego obiektu.

Np. pierwsza tabela zawiera tylko dane neutralne językowo (klucz podstawowy, itd.), a druga tabela zawiera jeden rekord na język, zawierający zlokalizowane dane oraz kod ISO języka.

W niektórych przypadkach dodajemy pole DefaultLanguage, dzięki czemu możemy wrócić do tego języka, jeśli nie są dostępne lokalne dane dla określonego języka.

Przykład:

Table "Product":
----------------
ID                 : int
<any other language-neutral fields>


Table "ProductTranslations"
---------------------------
ID                 : int      (foreign key referencing the Product)
Language           : varchar  (e.g. "en-US", "de-CH")
IsDefault          : bit
ProductDescription : nvarchar
<any other localized data>

Z takim podejściem, możesz obsługiwać dowolną liczbę języków (bez konieczności dodawania dodatkowych pól dla każdego nowego języka).


Aktualizacja (2014-12-14): proszę spojrzeć na ta odpowiedź , aby uzyskać dodatkowe informacje na temat implementacji używanej do ładowania wielojęzycznych danych do aplikacji.

 174
Author: M4N,
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:33:26

Uważam, że tego typu podejście działa dla mnie:

Product     ProductDetail        Country
=========   ==================   =========
ProductId   ProductDetailId      CountryId
- etc -     ProductId            CountryName
            CountryId            Language
            ProductName          - etc -
            ProductDescription
            - etc -

Tabela ProductDetail zawiera wszystkie tłumaczenia (dla nazwy produktu, opisu itp..) w językach, które chcesz obsługiwać. W zależności od wymagań aplikacji, możesz chcieć rozbić tabelę krajów, aby używać języków regionalnych.

 13
Author: Nick,
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
2009-05-30 09:40:45

Polecam odpowiedź zamieszczoną przez Marcina.

Ale wydaje się, że martwisz się, że Twoje zapytania stają się zbyt złożone:

Tworzenie zlokalizowanej tabeli dla każdej tabeli wymaga skomplikowanego projektowania i zapytań...

Więc możesz myśleć, że zamiast pisać proste zapytania Jak to:

SELECT price, name, description FROM Products WHERE price < 100

...musisz zacząć pisać takie zapytania:

SELECT
  p.price, pt.name, pt.description
FROM
  Products p JOIN ProductTranslations pt
  ON (p.id = pt.id AND pt.lang = "en")
WHERE
  price < 100
Niezbyt Ładna perspektywa.

Ale zamiast robić to ręcznie ty powinieneś opracować własną klasę dostępu do bazy danych, która wstępnie parsuje SQL, który zawiera specjalne znaczniki lokalizacji i konwertuje go do rzeczywistego SQL, który będziesz musiał wysłać do bazy danych.

Używanie tego systemu może wyglądać mniej więcej tak:

db.setLocale("en");
db.query("SELECT p.price, _(p.name), _(p.description)
          FROM _(Products p) WHERE price < 100");
I jestem pewien, że możesz to zrobić jeszcze lepiej.

Kluczem jest jednolita nazwa tabel i pól.

 12
Author: Rene Saarsoo,
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
2009-05-30 10:37:52

Używam następnego podejścia:

Produkt

ProductID OrderID,...

ProductInfo

ProductID Tytuł Nazwa LanguageID

Język

Język Nazwa Kultura,....

 8
Author: omoto,
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
2009-05-30 09:38:40

Rozwiązanie Martina jest bardzo podobne do mojego, jednak jak radzisz sobie z domyślnym opisem, gdy żądane tłumaczenie nie zostanie znalezione ?

Czy wymagałoby to IFNULL () i innej instrukcji SELECT dla każdego pola ?

Domyślne tłumaczenie będzie przechowywane w tej samej tabeli, gdzie flaga taka jak "isDefault" oznacza, że opis jest domyślnym opisem w przypadku, gdy żaden nie został znaleziony dla bieżącego języka.

 2
Author: doM,
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
2009-08-24 14:39:08