Например у меня есть много моделеи (до 30) каторые имеют поле name. Но так как ета програма дла несколких языков, то в модели есть такие поля:

А если мне надо добавить есчо адин язык ? Хочется держат тексты гдето оддельно. Но где ? В оддельной таблице думал, но тогда при стартупе придется грузить до 500.000 строк (для 3 языков). Да и как потом их использовать? В йсп я должен изпользовать чтото типо ${product.name} и оно должно вывести то name, для которого включена локаль. Как ви решали или решили би подобную проблему ?

Для начала можно почитать вот эту доку. А в целом нужно смотреть на решения по интернационализации предоставляемые вашим фреймворком. В сущности такие поля не добавляют.

Использю Spring 3.0 MVC, но както ненахожу, что могбы в нем использовать для речения своеи проблемы.

а зачем в базе хранить разные поля для каждого языка?

i18n со своими бандлами не решает проблему интернационализации хранимых объектов.. имхо.
Тут надо мутить какую-то связь. Так, если по-быстрому, то я бы сделал так: 




А дальше, получается, когда тебе нужно вынуть, к примеру, перевод продукта на хранцузском, делаешь 



ну и сам метод 


Это то, что пришло в голову самое первое. А вообще, наверное, есть и другие варианты. Можно сделать и более гибкий и более абстрактный объект LanguageTranslation, в который можно было бы забрасывать совершенно разные объекты... думать надо

Неахота писать для 30 моделеи есчо 30 ModelNameLanguages (вет ето есчо 30 таблиц в базе данных).



Ето вы имели ввиду, чтобы был какойто сервис ? Да ето возможн, с ДАО получаеш лист обектов, подаеш в некий сервис и он записывает в поле модели name имя по включенной локали (например селетит из одной таблицы перевод для всех моделеи).

А может както возможо с hibernate interceptor, hibernate custom user type ?

Добавлено через 57 секунд


А как иначе ?

Вы меня не поняли, ну и ладно, теперь зато я понял.   

Мне честно говоря тяжело представить задачу, где нужно интернационализировать сущности... Обычно такая операция относится к заголовкам страниц, служебной информации, всякие там лицензионные соглашения, надписи на кнопках.. Но что бы имя, пусть того же, продукта...  А как пользователь будет вынужден создавать такой продукт? Вводить название на всех языках или только на том с какой локали он работает? А что если нет выбранной локали в БД? Тут предстоит учесть не мало мелочей. 

Нет, он сначала выберает, кокого типа продукт он создает.  Так вот ети типы и можно через админ редактировать. А усер просто видет каталог типов продуктов с именами в его локали.


Усер в интерфейсе сможет выберать толко те локали, которые запрограммированные в программе.

В таком случае, думаю, вам придется реализовывать логику управления  такими сущностями самостоятельно. 
Например создать класс для хранения локализованного значения имени и сделать связь коллекции таких имен с вашим продуктом.

Может быть имеет смысл использовать Map вместо List. В общем такая логика будет находиться под ответственностью вашего приложения, фреймворк, увы, не сможет взять её на себя.

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

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



Только как потом примапить с Hibernate'ом в сущность product, все переводы где clazzName='Product' и objectId = ид продукта, чтобы било чтото такого:
 

Как описать такой маппинг с hibernate. Притом в Translations маппинга наверно небудет, так как его будет использовать много сущностей.

Вчера еще возникло похожее решение, но не успел отписаться. По-моему, оно будет более гибкое. 




В базе будет получаться что-то вроде такого


Таким образом можно переводить значения любых полей любого объекта. Относительно любого, конечно. 

Если очень хочется связей, чтобы дергать product.getTranslations(), то самым простым вариантом будет создать базовый класс, в котором прописать маппинг на TranslatableObject, и унаследовать от него все свои 30 хранимых объектов. Получится всего 2 дополнительных таблицы в базе. Код примерно такой



Но мне кажется, что лучше обойтись без мапинга. Проще будет, не будет проблемы lazy collections и всего такого. Просто заюзать TranslatableObject, Locale и какой-нибудь TranslatableObjectDao.




Это сообщение отредактировал(а) afon - 22.1.2010, 13:55

А в чем заключается проблема lazy collections ? Я как понимаю, если есть маппиг, то ненадо будет самому писать селекты минус один дао. А по перформацу, то какя раазница или я руками или хибернате выташит ети данные ?

Да и подумал, что так просто примапить мы несможет, так как фореигн кей будет неуникалным - в каждой таблице (из моих 30) может быть запись с ид=10. То если в TranslatableObject записать objectId=10, то етот TranslatableObject приампится для каздой сушности с ид=10. Я думаю надо будет дополнительно селектить и указывать simpleClassName. А после селектита создавать DTO обьект. Только получается что мне надо иметь сервис каторый будет трансформировать из хибернате обьекта в DTO и который поселектит переводы и запишет в DTO. 

Такчто сценарий такой:
1. Селектим хибернате обьекты из DAO.
2. С поможю сервиса конвертируем результат в DTO.

Как вам идея ? Какая критека ? 

Критека канткретная    читать то, что вы пишите, очень трудно. Так что уж потрудитесь...
А по сути: да дальше уже ваша собственная фантазия и конкретные прикладные проблемы все сделают. Мапить или нет, на какой id, сделать ли какой-то глобальный JoinTable верхнего уровня... зависит от  самого проекта. Дальше даже советовать трудно, не зная области... .

Это сообщение отредактировал(а) afon - 25.1.2010, 12:14

Возникла подобная необходимость, пока остановился на том, чтоб в данные для разных локалей хранить в одной таблице(добавив поле локали). При выборке данных задавать необходимую локаль.
Недостатком является, как написал товарищ powerOn, самостоятельная реализация логики для управления сущностями. Зато  не нужно забивать память неактуальной инфой для остальных локалей(как в первом посте).