До сих пор было несколько вопросов по этому вопросу, и все они пришли к одному и тому же ответу: одна таблица для нейтральных по отношению к региону данных, 1- * к таблице с переводами и индексированному языковому идентификатору.
У этого есть несколько проблем:
- В два раза больше CRUD.
- Необходимость для Ajax CRUD, если вы хотите дружелюбный веб-интерфейс.
- Более чем в два раза валидация - вам нужно убедиться, что отношение равно 1- *, а не 0 - *.
- Различия между языками не учитываются.
- Запросы требуют объединения.
- Если вам нужны пули на разных языках, о мальчик.
Многие люди из базы данных работали над всеми видами теоретических и практических проблем, но на удивление мало кто работает над этим.
Я думаю, что в конечном итоге нам нужно:
- Тип поля, в котором будут храниться несколько версий строк.
- Несколько индексов для каждого такого поля, по одному для каждого языка или вариации, с возможностью указать правильный режим сортировки
- Стандартный объект ORM для этой сумасшедшей вещи
- Элементы пользовательского интерфейса
Overkill? Конечно, возможно, но вся проблема - настоящий кошмар, какой он есть. И это не совсем необычный сценарий.
Мы должны попытаться убедить поставщиков серверов работать над этим.
Изменить:. Кстати, это мой первый раз, используя вики сообщества. надеюсь, я делаю это правильно.
Изменить 2: Что-то в моей формулировке, похоже, заставило людей думать, что я атакую саму концепцию СУБД. Я не; Я просто говорю, что встроенная поддержка локализации является очень необходимой функцией.
Я, вероятно, не должен упоминать о производительности; это, конечно, совершенно незначительно в большинстве случаев. В центре моей озабоченности находится тот факт, что это действительно снижает производительность.
Я приведу пример. Предположим, у меня очень тривиальная таблица для довольно тривиального хранилища:
Products (id, price, description, name, slug)
В EF/MVC я бы бросил это в ORM-дизайнере, возможно, инкапсулировал его в репозиторий, построил контроллер продуктов и имел действия для индекса, деталей, создания, обновления, редактирования и удаления. Чтобы идентифицировать продукт в любом из элементов, я бы просто сделал WHERE (slug = @slug). Я бы сделал модель представления для действий создания/редактирования, разработал элемент управления формой и подключил его прямо к репозиторию. Сделано и сделано. Чтобы получить доступ к деталям для продукта, пользователь перейдет к /products/details/product-slug.
Но так как остальная часть сайта двуязычна, я решил соответствующим образом изменить таблицу продуктов.
Products (id, price)
ProductsText (productId, language, description, name, slug)
Эй, это не так плохо. Да, еще нет. Затем вы пишете свои отношения и свои ограничения, а затем пишете вы пишете все свои свойства в модели вида, а затем вы создаете полный CRUD-контроллер для данных ProductsText или используете jQuery/Ajax для добавления кнопок создания/обновления/редактирования на вашем контроллере Products, а затем добавьте логику проверки, чтобы убедиться, что пользователь вводит, по крайней мере, основной язык, а затем, когда вы хотите читать данные для страниц конечного пользователя, вы пишете еще один запрос, чтобы присоединиться к ProductsText.slug и ProductsText. язык с продуктами... Я, наверное, что-то пропустил, но вы поняли идею.
Сложность программы просто взрывается с помощью шаблона кода, если вы используете локализацию.
Конечно, я не ожидаю, что проблема будет решена полностью, и это, очевидно, так же, как и проблема интерфейса, поскольку это проблема с базой данных. Но есть так много, что можно сделать, чтобы сделать все это проще. "Многостраничный" тип поля может быть действительно хорошим началом.
Изменить 3: Кто-нибудь слышал о SQL Server Modeling Services? Он имеет некоторые инструменты локализации, которые могут быть шагом в правильном направлении. Тем не менее CTP.
-- Simulate the French locale with the SET LANGUAGE statement.
SET LANGUAGE French
select Id, CountryName,
[System.Globalization].[SessionsString](CountryName, 1) as CountryNameString
from [Location].[CountriesTable]