Локализация базы данных - списки поиска - умнее

Question

Я хочу добавить несколько списков поиска в базу данных, но я хочу, чтобы они были легко локализуемыми (SQL 2005, ADO.NET)

Это будет включать:

• Простое управление несколькими языками одновременно
• Простой поиск значений из базы данных
• Резервный язык (в случае отсутствия выбранного языка)

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

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

Я ищу решение, которое позволило бы мне отправить параметр в виде "сеанса / глобальной переменной" или которое автоматически отправило бы параметр с помощью запроса sql, а также функцию для его извлечения (либо для присоединения параметр автоматически, либо для возможности чтения параметра).

Решение может выглядеть примерно так, но я не против, если оно будет другим, если оно явно не передает параметр в Запрос (псевдокод):

1. Send the language using "the method"
2. Execute Query
3. Get the localized results

Пояснение:

1. Обычно запрос будет выглядеть так (не забывайте использовать функцию поиска):

   SELECT .., GetLookupList1(lookup_ID, language), .. FROM TABLE

GetLookupList1 - это пользовательская функция, которая извлекает значение поиска для таблицы поиска. С помощью этой функции код SQL легче читать и поддерживать.

Тело функции будет выглядеть примерно так:

SELECT @result = LookupValue FROM LookupTable1 WHERE ID=@Lookup_ID and Language=@lang
RETURN @result

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

   SELECT .., GetLookupList1(lookup_ID), .. FROM TABLE

Answer 1

Поскольку в SQL Server нет пользовательских глобальных переменных, вам придется использовать один из двух подходов:

1. Таблицы - временные или постоянные. Пример с постоянными таблицами: http://weblogs.sqlteam.com/mladenp/archive/2007/04/23/60185.aspx.
2. SET CONTEXT_INFO: http://msdn.microsoft.com/en-us/library/ms187768.aspx. Context_info позволяет вам связать 128 двоичных байтов с сеансом / соединением. Это работает, но будьте осторожны. Если вы привыкли использовать его, вы рискуете случайно перезаписать его в другом контексте. Там только один за сеанс / соединение.

Пример context_info t-sql:

declare @languagein varchar(30), @contextin varbinary(128),
    @languageout varchar(30), @contextout varbinary(128)

select @languagein = 'ro-RO'
select @contextin = cast(@languagein as varbinary(128))
set context_info @contextin

--do whatever you like here: queries, stored procs. 
--context_info stays 'ro-RO' for the duration of the session/connection

select @contextout = context_info()
set @languageout = replace(cast(@contextout as varchar(30)),0x00, '')
print @languageout

Другая техника, которую я использовал в локализации, состоит из трех частей, чтобы гарантировать результат. Сначала проверьте язык-регион, затем язык, затем значение по умолчанию. По вашему запросу:

SELECT COALESCE(langregion.LookupValue, lang.LookupValue, fallback.LookupValue) LookupVal
FROM LookupTable1 fallback
LEFT OUTER JOIN LookupTable1 lang 
    ON lang.ID = fallback.ID AND lang.Lang = @language
LEFT OUTER JOIN LookupTable1 langregion 
    ON langregion.ID = fallback.ID AND langregion.Lang = @languagewithregion
WHERE fallback.ID = @Lookup_ID
AND fallback.Lang = @defaultlanguage

Answer 2

Если вы структурируете свои данные следующим образом:

MessageToken    DisplayText       LangCode
firewood        Fire wood         en
firewood        Bois de chauffage fr

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

Select DisplayText from (some table) where MessageToken = 'firewood' and LangId = 'en'

Answer 3

После детального изучения проблемы я обнаружил следующее:

1. Я мог бы использовать SET CONTEXT_INFO, но мне пришлось бы ввести немного SQL для решения проблемы.

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

Спасибо за ваши ответы.