Есть БД (MSSQL) достаточно большого объема (миллионы записей, сотни таблиц). Нужно реализовать (.NET) хранение в БД локализованных строк.
Локализация на три языка. Я вижу два варианта решения вопроса:
1. Расширить таблицы БД, введя в них по три колонки (по количеству языков локализации) на каждую колонку в которой будет хранится локализованный ресурс. к примеру. Если у нас есть таблица Order: Id, Count, Name, Description; то на выходе мы получим Order: Id, Count,NameL1,NameL2,NameL3,DescriptionL1,DescriptionL2,DescriptionL3.
Минус данного решения в усложнении процедур поиска, так как мы точно не знаем на каком языке нам нужно искать данный ресурс. Т.е. поиск будет всегда по трем полям. Также минус в том, что для локализации придется писать программу для переводчиков.
2. В поле хранить некую ссылку (к примеру, id) на внутреннюю локализацию (которая будет реализована в виде xml ресурсных файлов). Минусы — усложнение процедуры поиска, и, видимо, увеличение его времени, так как сначала нужно будет поискать в 3х xml файлах нужную запись, а, затем, найти ее соответствие в БД.

Возможно есть другие варианты и я что-то упускаю? Как вы решаете подобные проблемы?

Здравствуйте, Аноним, Вы писали:

А>Есть БД (MSSQL) достаточно большого объема (миллионы записей, сотни таблиц). Нужно реализовать (.NET) хранение в БД локализованных строк.
А>Локализация на три языка

Вариант 1 — удобно для интеропа с переводчиками: завести несколько таблиц (Resources_ru_RU, Resources_en_US) с одинаковыми ключами для одинаковых строк. Появился новыё язык? Выгрузить Resources_ru_RU в csv, отдать переводить, загрузить как Resources_sq_AL. Джойнить в зависимости от локали.

Вариант 2 — табличка OrderTranslations (OrderID, Name, Description...). Хз зачем, если честно

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

А>внутреннюю локализацию (которая будет реализована в виде xml ресурсных файлов).

Не советую, гражданин… мнэ-э… не советую. Съедят.

(с)

А>Возможно есть другие варианты и я что-то упускаю? Как вы решаете подобные проблемы?
Локализовать надо всю БД или только справочники?

Здравствуйте, LF, Вы писали:

LF>Локализовать надо всю БД или только справочники?
Справочники. Пару десятков таблиц. Для понимания, к примеру, есть таблица: Country: Id, Name, PhoneCode ... Соответственно на нее есть ссылки в других сущностях (через Country.Id) — типичный справочник, который нужно локализировать.

Здравствуйте, Sinix, Вы писали:

S>Вариант 1 — удобно для интеропа с переводчиками: завести несколько таблиц (Resources_ru_RU, Resources_en_US) с одинаковыми ключами для одинаковых строк. Появился новыё язык? Выгрузить Resources_ru_RU в csv, отдать переводить, загрузить как Resources_sq_AL. Джойнить в зависимости от локали.
Джойнить от локали не получится, так как помимо отображения пользователю там еще и поиск идет (а он по всем локалям должен быть, а то данные попадают на разных языках).

Не понимаю, а почему тогда не сделать просто таблицу ResourceLocalization: Id, Ru, En. А из других таблиц просто давать ссылку на Id в любом поле. Как я понимаю, проблема будет в нагрузке на БД. Так как сначала нужно будет искать совпадение в ResourceLocalization, а, затем, уже в требуемой таблице соответствующий найденный Id.

S>Вариант 2 — табличка OrderTranslations (OrderID, Name, Description...). Хз зачем, если честно

К примеру: Пусть у нас есть Country: Id, Name
Russia, Россия
USA, США
...
нужно по текстовой строке, переданной в программу извне найти соответствующую страну. К примеру, эта строка сша (а ведь могут быть и синонимы, типа Соединенные Штаты, Америка и т.п. и среди этих синонимов только один вариант можно отобразить пользователю, к тому же он должен быть на его языке). Т.е. сейчас я больше склоняюсь к версии
Country: Id
CountrySynonym: Id, CountryId, LocalizationId, Name, Visible
LocalizationId просто числа от 1 до кол-ва языков, либо ссылка на отдельную таблицу храняющую названия зыков и их Id, но я не вижу в ней смысла.
Напрягает конечно на каждую таблицу вести дополнительную таблицу синонимов.

Здравствуйте, Аноним, Вы писали:

А>Джойнить от локали не получится, так как помимо отображения пользователю там еще и поиск идет (а он по всем локалям должен быть, а то данные попадают на разных языках).
Ничего не мешает сделать view и искать по нему. Вы же не на клиенте ищете, так?
Главный смысл в нескольких таблицах — чтоб не возиться с foreign key.

А>Не понимаю, а почему тогда не сделать просто таблицу ResourceLocalization: Id, Ru, En.
Можно и так. Эт по вкусу, кому что больше нравится.

А>К примеру: Пусть у нас есть Country: Id, Name
А>нужно по текстовой строке, переданной в программу извне найти соответствующую страну.
Индексы по столбцам и вперёд Для самых жрущих запросов — либо indexed view, либо заполнять триггером маленькие таблицы.

А>Напрягает конечно на каждую таблицу вести дополнительную таблицу синонимов.
От-от. Ещё и поддерживать всё это щастье: импорт-экспорт, обработка самой программой и т.п.