Структура базы данных многоязычного сайта

Question

Мне нужна структура базы данных для хранения версий контента сайта на разных языках. Прямо сейчас я делаю это так:

[Item]  
Id  
SomeColumn  

[ItemStrings]  
ItemId  
LanguageId  
Title  
Description  
...

[Languages]  
Id  
Culture  

Несмотря на то, что это довольно аккуратный способ сделать перевод, он требует большого количества обезьяньего кодирования при добавлении новых объектов в систему.
Другим решением, о котором я подумал, была некоторая глобальная таблица для ВСЕХ строк, которые необходимо перевести, с уникальным идентификатором и идентификатором языка в качестве первичного ключа.
Мне нравится второй способ гораздо больше, потому что он более сухой.

Теперь реальный вопрос: могу ли я использовать nvarchar (MAX) для всех моих записей? Будет ли он потреблять гораздо больше памяти, когда, скажем, только 20% значений будут стоить varchar (max), а другие легко поместятся в nvarchar (50 с чем-то)?

Я использую SQL Server 2008.

Answer 1

В последнем проекте, над которым я работал, ключом была английская фраза, а не ID. Это облегчило написание кода. Вы вызываете метод GetTranslationFor («Английская фраза», культура); в отличие от GetTranslationFor (123, культура);

Тогда ваши разработчики просто пишут код и не тратят время на поиск идентификаторов для нужной фразы или их добавление. Пусть метод GetTranslationFor отправит уведомление по электронной почте администратору, если он не найдет перевод фразы в базе данных, поэтому его можно добавить, НО вернитесь к введенной фразе.

Лучше показывать английскую фразу на французском сайте, чем какую-то ошибку или ничего.

И nvarchar max должен быть в порядке.

ps То, что я говорил, это то, что ваш второй метод выглядит хорошо, я бы просто добавил дополнительный ключ / индекс, используя в качестве ключа английскую фразу.

Answer 2

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

Что касается использования nvarchar (MAX), это должно быть хорошо. типы varchar занимают столько места, сколько им нужно.

Answer 3

У меня был бы ключевой столбец (именованные объекты, например, «OKAY», «SaveAs» и т. Д. - достаточно nvarchar (32)) и языковой столбец (я использовал бы код, такой как EN-UK для британского Английский, поэтому char (5)), поскольку они стандартизированы. Эти два столбца будут уникальным индексом / первичным ключом. Тогда у меня будет столбец для фактического текста - столько, сколько вам нужно, nvarchar. Я думаю, что столбец / таблица / база данных должны быть в UTF8?

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

У меня также есть запасной вариант, когда перевод недоступен, поэтому сделайте так, чтобы ваш запрос получал EN-US, если запрашиваемый язык не имеет значения. Лучше иметь что-то, чем ничего.