Архитектура базы данных проектирования: БД для использования с несколькими разными языками - PullRequest
Новая
       10

Архитектура базы данных проектирования: БД для использования с несколькими разными языками

1 голос
/ 02 августа 2010

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

У меня есть одна идея, как это реализовать.Но мне это не очень нравится.

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

Например, для таблицы Project, содержащей три строкиполя (name, shortDescr, fullDescr) Я буду использовать таблицу перевода следующим образом:

альтернативный текст http://a.imageshack.us/img576/7948/2deldbtop.png

Я изменю поля name, shortDescr, fullDescr со строки на целое (чтосодержать ссылку (ID) на translationTxtID).Различные поля translationTxtID и lang будут определять уникальную строку для каждого строкового токена и языка.Так что это решение будет работать, но я ищу более элегантное решение.Можете ли вы предложить мне решение этой проблемы.

Ответы [ 5 ]

4 голосов
/ 02 августа 2010

Можете ли вы предложить мне решение этой проблемы?

Да.

Не используйте целочисленные ключи.В самом деле, не изобретайте это самостоятельно.Просто используйте gettext.У вас уже есть это доступно практически на каждой операционной системе.Это быстрое, проверенное программное обеспечение, которое вам не нужно писать.

Делайте то же, что и стандартный модуль gettext для i18n.(см. http://en.wikipedia.org/wiki/GNU_gettext)

  1. Использовать текстовые ключи.

  2. Выберите локаль (т. е. локаль "C" или локаль, в которойВы написали программное обеспечение).

  3. Поместите все сообщения в таблицу «Project» в виде строк в локали по умолчанию.

  4. Поместите всепереводы в таблицу «Translation» с исходной строкой и языковым стандартом I18N для ее перевода. Да, таблица перевода имеет большую длинную строку. Это прекрасно работает на практике, потому что (1) у вас не так много строк, (2) вы не часто просматриваете их, и (3) вы должны использовать gettext, а не свой собственный.

  5. Когда вы предоставляете какие-либо данные пользователю, вы пытаетесь выбрать SELECT, чтобы получить перевод. Если вы нашли перевод, это хорошо.

    Если вы не нашли перевод, то ключом, который вы используете, является строка по умолчанию, которая лучше, чемНичего. Зарегистрируйте исключение где-нибудь и представьте оригинальную строку.

0 голосов
/ 22 июня 2012
В 1000*
0 голосов
/ 03 августа 2010

Мой выбор 

Project
-------
ProjectID (PK)
Date

ProjectLoc
----------
ProjectID (FK)
Lang
Name
ShortDesc
FullDesc

Тогда вы можете выполнить простой запрос, например 

SELECT Project.ProjectID, Date, Name, ShortDesc, FullDesc
FROM Project
LEFT JOIN ProjectLoc ON Project.ProjectID = ProjectLoc.ProjectID
WHERE ProjectLoc.Lang = %CurrentLang%

Плюсы: Элегантный и простой
Минусы: Большое количество таблиц

0 голосов
/ 03 августа 2010

Я использую таблицу локализации для каждой родительской таблицы, которая содержит строки. Поэтому, если у вас есть таблица «Project», у вас также будет таблица «Project_Locale». Project_Locale имеет тот же PK, что и Project + добавление поля "Культура". Все локализуемые строковые поля помещаются в Project_Locale, а все остальное - в Project.

0 голосов
/ 02 августа 2010

Почему бы не иметь несколько записей в таблицах, по одной для каждого языка? PK может быть комбинацией ID и LangID. Для вашего примера выше: 

Project

ID, int
LangId, int
Name, varchar
shortDesc, varchar
Fulldesc, varchar
date, date

Тогда все, что вам нужно сделать в вашем коде, это установить языковую переменную, а в ваших запросах указать ее как один из вариантов в запросе (здесь я использую SQL в качестве ссылки): 

SELECT (columns)
FROM Project
WHERE ID = @id
and LangId = @langid

Вы поддерживаете все запросы для этого конкретного сеанса.

...