Каковы наилучшие методы разработки многоязыковой базы данных?

Каков наилучший способ создания многоязычной базы данных? Чтобы создать локализованную таблицу для каждой таблицы, вы создаете конструкторский и запросный комплекс, в другом случае добавление столбца для каждого языка является простым, но не динамическим, пожалуйста, помогите мне понять, что лучше всего подходит для корпоративных приложений.

Ответы

Ответ 1

Что мы делаем, это создать две таблицы для каждого многоязычного объекта.

например. первая таблица содержит только данные, не зависящие от языка (первичный ключ и т.д.), а вторая таблица содержит одну запись на каждый язык, содержащий локализованные данные, а также код ISO языка.

В некоторых случаях мы добавляем поле DefaultLanguage, чтобы мы могли вернуться на этот язык, если локализованные данные не доступны для указанного языка.

Пример:

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>

При таком подходе вы можете обрабатывать столько языков, сколько необходимо (без необходимости добавлять дополнительные поля для каждого нового языка).

Обновление (2014-12-14): см. этот ответ, для получения дополнительной информации о реализации, используемой для загрузки многоязычных данных в приложение.

Ответ 2

Я считаю, что для меня этот тип подхода работает:

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

В таблице ProductDetail содержатся все переводы (для названия продукта, описания и т.д.) на языках, которые вы хотите поддерживать. В зависимости от ваших требований к приложениям вы, возможно, захотите сломать таблицу Country, чтобы использовать региональные языки.

Ответ 3

Я рекомендую ответ, отправленный Мартином.

Но вы, похоже, беспокоитесь о том, что ваши запросы становятся слишком сложными:

Для создания локализованной таблицы для каждой таблицы выполняется проектирование и запрос сложного...

Итак, вы можете подумать, что вместо написания простых запросов вроде этого:

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

... вам нужно будет начать писать такие запросы:

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

Не очень красивая перспектива.

Но вместо того, чтобы делать это вручную, вы должны разработать свой собственный класс доступа к базе данных, который предварительно анализирует SQL, который содержит вашу специальную разметку локализации, и преобразует ее в фактический SQL, который вам нужно отправить в базу данных.

Использование этой системы может выглядеть примерно так:

db.setLocale("en");
db.query("SELECT p.price, _(p.name), _(p.description)
          FROM _(Products p) WHERE price < 100");

И я уверен, что вы можете сделать еще лучше.

Ключ должен иметь одинаковые имена таблиц и полей.

Ответ 4

Я использую следующий подход:

Продукт

ProductID OrderID,...

ProductInfo

Название названия продукта LanguageID

Язык

LanguageID Название Культура,....

Ответ 5

Решение Martin очень похоже на мое, но как бы вы обрабатывали описания по умолчанию, когда нужный перевод не найден?

Для этого потребуется IFNULL() и другая инструкция SELECT для каждого поля?

Перевод по умолчанию будет храниться в той же таблице, где флаг, подобный "isDefault", указывает, что описание является описанием по умолчанию, если ни один не найден для текущего языка.