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

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

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

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

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


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

S>Solonik: Локализация "Немецский — австрийский" и "Немецкий — швейцарский" — это РАЗНЫЕ локализации, согласен. Но разве необходимо их объединять в иерархии?
Скорее всего — да. В австрийскую ложить только те слова, которые отличны от базовых немецких.
Тогда уровень — базовая локализация (По умолчанию пусть английская)-> национальная (немецкая)- диалект(автрийская). 3 уровней хватит
Еще флаг — локализация из нижнего уровня.
Если происходит вставка новой записи — то она вставляется во все локализации до самого верха. Немецкий — вставим тоже и в английский + флаг. Автрийская — немецкий — английский+ флаги.
Обновление — обновляем все вверх, до тех пор тока стоит флаг локализация нижнего уровня.


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

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

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

В дополнение к твоему вариату: в момент запуска приложения создавай временную таблицу в которой лежит нужная локация. Простым переносом данных. Текущая локация + для отсутвующих локация по умолчанию Тогда запросы будет легче делать -обращаться к одной таблице. Правда тут встает вопрос ее обновления в момент вставки и update. Но что придумать можно — типа сервиса обновлений.