Для реализации мультиязыковости в БД было реализовано следующие: все поля с требующими локализации строками были заменены ссылками на некую таблицу-ресурс этих строк. Т.е. была введена таблица TITLE (title_id, language_id, value). К примеру, таблица STATUS (status_id, name) изменилась на STATUS (status_id, title_id). В каждый момент времени выбираются данные по параметру - language_id. Если ли какие-нибудь методы, подходы для выборки подобных данных? Теоретически можно вытаскивать все строки для всех существующих языков, но ИМХО это не совсем правильно.

Забыл пароль .. wrote:
> незаметил про Hibernate, если некритичнен контроль только на стороне AS
> то можно при выборе локали использовать пакетные переменные и вьюшку для
> текущей сессии (для оракла, с другими не работал), плюс ненадо
> перегенерить мэппинги, минус логика частично уходит в базу

Насчет установки контекста сессии (т.е. контекста связанного с ней Connection) это мысль, спасибо.
Просто проект реализован на Oracle, а заказчик спросил, во что обойдется его расширение на другие
БД. пока что метод выбора локализованных значений из базы - один из вопросов, который хотелось бы
прояснить для принятия решения, стоит ли вообще этим заниматься.
Posted via ActualForum NNTP Server 1.3

Пока кроме как работы с контекстом сессии ничего путного в голокву не лезет. Т.е. это подразумевает обращение приложения не напрямую к таблицам, а в представлениям на их основе, где в нужных местах выводятся значения строк в зависимости от установленного контекста. Но это достаточно непереносимо в общем смысле: допустим, в MSSQL или Sybase или еще где найдется нечто подобное, но что делать с остальными БД, где такого может не быть? В-вторых, проблема с кешированием объектов: а вдруг поменялся язык.

Другая мысль: читать строки на всех языках в некий список, а уже на клиенте выбирать нужный, исходя из текущего языка.

Как вообще можно справиться с такой структурой?

Вот еще что придумал: в БД делается слой представлений (VIEW) и Hibernate подсовываются именно они, а не таблицы. Для STATUS это примерно так:


Т.е. получается декартово произведение по всем языкам. В Hibernate прописываем фильтр :

и устанавливаем его для сессии. Тоже не особенно нравится: куча представлений и предполагаемая необходимость instead-of триггеров на них, которые не везде есть - почти полноценный еще один слой логики.

С фильтрами выходит не все так прекрасно. Они, как я понял, налагаются именно на ту сущность, которая выбирается в данный момент. Но допустим, что есть некий класc Document, у него есть поле Status вышеописанного класса - при выборке "from Document" статусы уже фильтроваться не будут: "Hibernate3 adds the ability to pre-define filter criteria and attach those filters at both a class and a collection level .".