Здравствуйте, всезнающий ALL !
Помогите пожалуйста с советом.

ПРОБЛЕМА:
Спроектировать структуру базы данных, позволяющую одновременно хранить локализованные данные для каждой сущности.

ОПИСАНИЕ ПРОБЛЕМЫ:
Допустим в БД имеется множество таблиц, в которых содержатся текстовые атрибуты (наименования запчастей, марки, пояснения, описания)
Требуется при локализации системы иметь возможность добавлять в базу данных переведенное на местный язык содержимое текстовых атрибутов, не меняя структуры базы данных. Количество таких локализаций заранее не известно. Т.е. для таблицы, хранящей описание некого прибора нужно уметь добавлять описание на английском, немецком, французском и еще на каком скажут языке.
И так практически для всех таблиц в БД. Не знаю, что делать. Добавлять по 20 атрибутов к каждому текстовому атрибуту для английской, немецкой, французской и т.д. версии некрасиво. Хочется просто иметь возможность выбрать в программе из меню нужный вариант локализации, а чтоб из базы по запросам выдавалась только локализованная информация.

ВОПРОС: как это обычное делают в профессиональных решениях?

Аноним пишет:
> ВОПРОС: как это обычное делают в профессиональных решениях?

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

Ну, еще в голову приходит что-нибудь вроде

<en-US> Pentium 4 2.8 </en-US>
<ru-RU> Чухня полная</ru-RU>
<fr-FR> La Pen' 4</fr-FR>

Но рано или поздно столкнешься с ограничением на 8000 символов.

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

А>Здравствуйте, всезнающий ALL !
А>Помогите пожалуйста с советом.

А>ПРОБЛЕМА:
А>Спроектировать структуру базы данных, позволяющую одновременно хранить локализованные данные для каждой сущности.

А>ОПИСАНИЕ ПРОБЛЕМЫ:
А>Допустим в БД имеется множество таблиц, в которых содержатся текстовые атрибуты (наименования запчастей, марки, пояснения, описания)
А>Требуется при локализации системы иметь возможность добавлять в базу данных переведенное на местный язык содержимое текстовых атрибутов, не меняя структуры базы данных. Количество таких локализаций заранее не известно. Т.е. для таблицы, хранящей описание некого прибора нужно уметь добавлять описание на английском, немецком, французском и еще на каком скажут языке.
А>И так практически для всех таблиц в БД. Не знаю, что делать. Добавлять по 20 атрибутов к каждому текстовому атрибуту для английской, немецкой, французской и т.д. версии некрасиво. Хочется просто иметь возможность выбрать в программе из меню нужный вариант локализации, а чтоб из базы по запросам выдавалась только локализованная информация.

А>ВОПРОС: как это обычное делают в профессиональных решениях?
Вопрос, а как планируется заполнение данной БД. При поступлении новой детали кто будет ее вводить и на скольких языках. Не убьют ли тебя пользователи при необходимости заполнять названия новой детали на всех существующих языках?
У меня при установке системы справочники по умолчанию заполняются на языке выбранном пользователем, а далее все в его руках.

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

А>ПРОБЛЕМА:
А>Спроектировать структуру базы данных, позволяющую одновременно хранить локализованные данные для каждой сущности.

Если речь идет о SQL 2005 — можно задействовать тип полей XML. Благо можно писать запросы не только на селект, но и на update/insert/delete отдельных узлови атрибутов, а также строить XML-индексы. Целостность можно проверять с помощью XMLSchema которая привязывается к тому же полю.

Здравствуйте, Ромашка, Вы писали:

Р>Аноним пишет:
Р>...Я создавал отдельную табличку в
Р>которой хранил идентификатор атрибута, его язык, тип атрибута и,
Р>собственно, его содержание...

Извините Ромашка, но я не понял это решение
Идентификатор кортежа знаю, а идентификатор атрибута что это?
Атрибут уже имеет тип при создании таблицы.
А список языков (локализаций) должен быть в отдельной таблице?

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

DS>Вопрос, а как планируется заполнение данной БД. При поступлении новой детали кто будет ее вводить и на скольких языках. Не убьют ли тебя пользователи при необходимости заполнять названия новой детали на всех существующих языках?

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

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

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

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

DS>>Вопрос, а как планируется заполнение данной БД. При поступлении новой детали кто будет ее вводить и на скольких языках. Не убьют ли тебя пользователи при необходимости заполнять названия новой детали на всех существующих языках?

А>Конечно, не убьют! Я буду далеко от них
А>В системе будет столько локализованных названий, сколько переводчики успеют сделать.
А>При добавлении нового наименования совсем необязательно надо заполнять на всех языках. Если пользователь включил в интерфейсе английский язык, то названия (деталей, отделов, должностей, описания, комментарии к ...) из базы данных должны браться только локализованные для английского пользователя, а если какой-либо ресурс не переведен например на английский, то система должна выдать текст в той локализации, которая по умолчанию в системе. Таким образом, если забыли что-то перевести, то хоть на русском, но по умолчанию пользователь что-то на экране увидит

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

локализация имеет смысл только когда с одной базой будут работать пользователи с разной локализацией. Имеет смысл только для справочников. Например,резолюцию руководства "Казнить нельзя помиловать" руководитель писать на 3-4 языках не будет.Так что лучше оставить 1 локализацию — принятую в рамках компании. З
Твой вариант сложен разработкой и временем выборки. Программа должна поддерживать еще и уровни локализации. Немецкий. Немецский — австрийский. Немецкий — швейцарский. и т.п. Если нет локализации на украинском, то посмотреть на русском, если и его нет то английский как пример.
Стоит ли овчинка выделки?
Ведь после внедрения программы, когда ты будешь далеко, данные будут вводить в нее в 99% случаев только на 1 языке.
Подумай про поиск. Тебе надо найти все детали в названиях которых присутвует некое слово сочетание. Если она будет просматривать всю локализацию, то может вывести лишнее или наооброот не взять.
Еще раз подумай а стоит ли овчинка выделки?

Здравствуйте, 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: Поиск будет делаться по выбранной пользователем локализации.

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

Здравствуйте, 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. Но что придумать можно — типа сервиса обновлений.

Аноним пишет:
> Извините Ромашка, но я не понял это решение
> Идентификатор кортежа знаю, а идентификатор атрибута что это?
> Атрибут уже имеет тип при создании таблицы.

А теперь попробуйте оторваться от терминологии баз данных и посмотреть
на это с точки зрения бизнес-логики. Атрибут это какое-либо свойство
сущности (например, в вашем случае, запчасти) как-то: наименование,
модель, описание и т. д. и т. п.. Собственно, каждая запчасть может
иметь свой собственный список атрибутов. Например, диски имеют диаметр,
который совершенно неприменим, например, к торпеде. Ввиду множества
атрибутов каждой конкретной запчасти вообще удивительно, зачем их
хранить в одной таблице? Как по мне, так хранить нужно ссылку на
определенный атрибут.

Теперь вернемся к локализации. Итак, есть диск 17". Вбивая каждый
семнадцатидюймовый диск Вы каждый раз будете переводить слово "диск" на
всю кучу языков или таки ограничитесь одним разом? А вбивать число 17
будете в каждом случае или только для тех локализаций, где принято
измерять в дюймах? Может таки лучше один раз? А если заметите ощибку в,
например, итальянском? Переводчика и перебивать все диски?

> А список языков (локализаций) должен быть в отдельной таблице?

Он никому ничего не должен. Его вообще может не быть, этого списка. Он
легко выбирается select distinct — ом из списка атрибутов.

Спасибо, что еще не потерян интерес к моему вопросу

ПРОБЛЕМА:
Согласен, что каждый тип запчасти машины имеют свой набор атрибутов
У колеса — одни атрибуты, у мотора — другие атрибуты и т.д.

Если применить ООП, то "колесо" и "мотор" есть классы-потомки от
базового класса "деталь". Допустим, в базе данных хранится состав автомобиля
из деталей. Состав автомобиля из деталей от языковой локализации не зависит.

Итак, у нас есть таблицы: базовая "деталь" и потомки "колесо" и "мотор",
У каждой — только нужные ей атрибуты, характеризующие ее как сущность.

Есть текстовые поля в базовом классе-таблице "деталь", которые необходимо
локализовывать для местного использования на разные языки, и естественно,
что "состав автомобиля" из "деталей" никак не зависит от наличия локализованных
текстовых полей, комментариев к детали и прочих описаний на местных языках

ВОЗМОЖНОЕ РЕШЕНИЕ:
1. Создать таблицу-потомок "локализованная деталь" от базового класса "деталь",
куда перенести все атрибуты, требующие локализации: текст на местном языке,
вес и размеры в местных единицах измерения.

2. У таблицы "локализованная деталь" сделать альтернативный составной ключ из
(кода "детали" + кода "локализации").

3. Таким образом, состав автомобиля из "деталей" остается без изменений,
а для каждой записи в "детали" появляется запись-двойник в таблице "локализованная деталь"
с локализованым описанием детали по мере возможностей переводчиков.

4. Если "локализованная деталь" отсутствует, мы все равно можем "собрать" автомобиль
из "деталей" и отобразить его в интерфейсе (например, как 3D-модель)

5. Если надо выбрать конкретную локализацию, то остается задать код локализации
и выбрать из таблицы "локализованная деталь" только строки с нужной локализацией.
Тогда на экране будут надписи на выбранном языке, и в местных единицах измерения.

И все было бы хорошо, если бы таблиц, требующих локализации было мало, а их много,
поэтому появится много локализующих "таблиц-двойников" и схема БД превращается в запутанный
моток проволоки.

ВОПРОС:
все тот же: какие еще есть варианты множественной локализации содержимого баз данных?
Я извиняюсь, но предыдущие советы не совсем меня убедили, чувствую, что еще не исчерпан твоческий
потенциал ALL в решении данной проблемы.