Задача проектирования базы данных для многоязычного приложения

Question

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

в настоящее время у нас есть следующие таблицы

Destination
Transport
Places of Interests
user comments etc.

каждая таблица содержит много полей, таких как

Name
ShortDescription
LongDescription 

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

Я не уверен, как лучше всего разработать приложение для этого случая, мне пришло в голову одно, как добавить дополнительный столбец для каждой локали в каждой таблице, но это означает, чтоЛокальные вещи необходимо изменить с базы данных на уровень кода, и это совсем нехорошо.

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

edit1 После некоторого анализа и некоторого изумления один подходh, что пришло мне в голову, выглядит следующим образом.

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

    table languages
    -- uuid (varchar)
    -- language_id(varchar)
    -- name (varchar)  

    table Destination
    --uuid (varchar)
     other fields which are not part of internationalization.

table Destination_translation
-- id (int)
-- destination_id (int)
-- language_id (int)
-- name (text)
-- description(text) 

Любое ценное предложение для вышеупомянутый подход приветствуется ...

Answer 1

При интернационализации приложения ранее у нас была таблица значений на основе локали.Итак, мы сделали что-то вроде этого:

Создать таблицу с именем local_strings, состоящую из string_code, locale_code, value.Это содержит переводы различных ценностей.Таким образом, если бы вы перевели на три языка, было бы три записи с разными locale_codes для каждого string_code ..

Тогда каждая из основных таблиц, в вашем случае назначения, транспорта и т.д. имеет ссылкуstring_code в таблице local_strings.

Наконец, при запросе значений из базы данных, просто убедитесь, что вы всегда присоединяетесь к таблице local_strings и всегда используете текущую локаль пользователя.Кроме того, вы можете кэшировать эти значения в памяти, чтобы не всегда объединяться с этой таблицей.Тем не менее, по моему опыту, таблица никогда не бывает такой большой, так что нет ничего лишнего, чтобы просто присоединиться к ней.

Answer 2

Есть несколько вариантов решения этой проблемы:

1. Расширьте свои таблицы по столбцу локали и включите локаль в каждый запрос. Вы даже можете изменить индекс, включив в него столбец локали.
2. Создать отдельную таблицу для локализованных строк

Я бы определенно предпочел вариант 1, так как он делает таблицы все еще похожими на настоящие, и их все равно можно прочитать, посмотрев непосредственно на данные. Это также предотвращает необходимость выполнять подвыборы или объединения, что способствует повышению производительности. Преимущество варианта 2 заключается только в большей легкости для программиста административного интерфейса (если он у вас есть).