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

А>>Приходит в голову идея сделать для каждой таблицы TABLE_XXX ее "локализованный" двойник LOCALIZED_TABLE_XXX, у которого будет составной PRIMARY KEY из мигрировавшего ключа из TABLE_XXX.Id и мигрировавшего ключа из таблицы LOCALIZATION.Id
А>>Таблица LOCALIZATION будет хранить список доступных локализаций.

DS>1. локализация имеет смысл только когда с одной базой будут работать пользователи с разной локализацией. Имеет смысл только для справочников. Например,резолюцию руководства "Казнить нельзя помиловать" руководитель писать на 3-4 языках не будет.Так что лучше оставить 1 локализацию — принятую в рамках компании.

Solonik: Согласен, только ради справочников все и затевается. И деталь автомобиля в справочнике должна иметь один и тот же GUID в любых локализациях, но описание детали должно быть в состоянии пополняться локализованными пояснениями. Проблема в том, что такого рода справочных таблиц (классификаторов типов событий, реестров документов) много.


DS>2. Твой вариант сложен разработкой и временем выборки. Программа должна поддерживать еще и уровни локализации. Немецкий. Немецский — австрийский. Немецкий — швейцарский. и т.п.

Solonik: Локализация "Немецский — австрийский" и "Немецкий — швейцарский" — это РАЗНЫЕ локализации, согласен. Но разве необходимо их объединять в иерархии?


DS>Ведь после внедрения программы, когда ты будешь далеко, данные будут вводить в нее в 99% случаев только на 1 языке.
DS>Подумай про поиск. Тебе надо найти все детали в названиях которых присутвует некое слово сочетание. Если она будет просматривать всю локализацию, то может вывести лишнее или наооброот не взять.
DS>Еще раз подумай а стоит ли овчинка выделки?

Solonik: Поиск будет делаться по выбранной пользователем локализации.

ПРОСЬБА: высказать, какие еще слабые стороны в моем подходе и как бы Вы еще предложили решить такого рода вопрос
Спасибо за внимание