Чтобы не было двоякой трактовки - "справочные данные" - это статические данные, описывающие некое свойство сущности, так называемые "словари" - например, у меня это для сущности Пользователь - страна проживания, используемые языки, валюта использования и т.д., то есть данные, внесенные в БД (или другое хранилище) заведомо имеющие ограниченную длину и не подлежащие редактированию.
"Локализованные" - на N-ном количестве языков интерфейса.

Веб-проект. Spring (framework, MVC, Security). Hibernate.

Ранее в проекта всегда не парился с этим понятием и использовал отдельные таблицы в БД. Причем, для каждого языка создавал дополнительное поле (редактировал сущность), а изымал в основном, используя либо параметризованные запросы к БД с указанием требуемого поля, либо (значительн реже) - рефлексию для объекта-сущности. Пример Location:
idisotitle_entitle_frtitle_ru1usUSAUSAСША2caCanadaCanadaКанада
Ну, а дальше ссылался на идентефикатор - таблицы связывались.

Если количество языков заведомо неизвестно (планируется добавление и даже динамическое добавление), то в таблице можно оставить только iso (если ссылаться на пример), а в файлах с локализованными метками (xxxxx_en.properties, xxxxx_fr.properties) указывать название, типа location.us=USA, location.ca=Canada и т.д. Это как бы делает гибче работу с языками.

Однако мне очень не нравится черезчур активное использование БД для таких второстепенных задач: во-первых, обеспечивая целостность, приходится постоянно "дергать" зависимые таблицы. Вроде ерунда, но иногда так получается, что изымается сущность, у нее 2 зависимых таблицы с динамическим содержанием, а с ними - до десятка справочных! И при этом использование этих второстепенных данных фактически сводится к минимуму, так как для отображения/редактирования на клиенте на этот клиент отсылаются (или заполняется шаблон - тут это неважно) все эти справочники целиком, затем объект и еще проводится некая работа на клиенте для отображения соответствия справочным данным (из нашего примеру, отобразить страну пользователя в выпадающем списке всех стран). Я надеюсь, что смысл недовольства, который я хочу донести, понятен. Логичнее было бы вместо ссылки на идентефикатор из таблицы стран просто указать "us" (уникальный указатель), передать на клиент список стран, который уже хранится (память, диск) и также отобразить. Особо ни целостность, ни некие теоретические коллизии, не интересуют в рамках рассматриваемых проектов.

Для хранения данных, которые подразумевается динамически отображать на клиенте (скажем, по ajax-запросу), удобно было бы хранить уже готовый JSON в пропертях, типа такого:
location.list=[{"key":"us","val":"USA"},{"key":"ca","val":"Canada"}]
Как мне кажется, преимуществ по скорости уйма - крайне гибкая работа с локалями, максимально эффективная работа с данными для динамического запроса с клиента, так как содержимое пропертей "висит" в памяти, берется и отсылается уже в готовом виде. Так как известно, что такие "справочники" относительно небольшие - десяток-полтора с максимальным количеством до сотни, то памяти используется мизер.

Но! Я пока не вижу явных подводных камней, но интуиция мне говорит, что где-то есть подвох и я могу разочароваться в таком механизме. Так как я явно его не вижу, то хочу спросить - существует ли "правильное" использование справочных локализованных данных при описанных условиях?
Второе - я подключаю пропертиз в конфиге Спринга как-то так:


Файлы пропертей загружаются Спрингом при старте проекта. Если я хочу сделать динамическое изменение данных, то как обновить их в контексте Спринга, не перегружая проект? - Думаю, вопрос несложный, и наверняка найду несложное решение, но и вопрос, в принципе, второстепенный.

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

Сразу видно, что вопрос ты не читал, потому что ссылка показывает обычную работу докализации, которая у меня реализована. И совершенно не отвечает на поставленный вопрос.

Да уж. Зря я второй вопрос задавал - он и не особо актуален, да и теоретически решаем достаточно просто - берем бин и заменяем в нем данные. Тут особо и придумывать не надо.

Основной, главный, превалирующий и т.д. вопрос - правильна ли техника, которую я применил с локализованными справочниками в пропертях? - А то придумать - придумал, но не уверен в правильности. Как говорил, чую, что будут подводные камни.

Уже что-то. Сенкс.

Сначала принял стандартную - "реляционную" - модель как правильную, но опять наталкиваюсь на стену.

Суть вот в чем ... при уже ИМЕЮЩЕЙСЯ структуре, например, рассмотренной выше
idisotitle_entitle_frtitle_ru1usUSAUSAСША2caCanadaCanadaКанада
действительно - пользуйся не хочу.

Но если я хочу более-менее автоматизировать добавление нового языка к проекту (например, в админке)? Допустим, новое поле в таблице БД сделать не проблема, но класс-сущность, представляющий таблицу, я уже не изменю, и полноценный HQL-запрос не сделаю. Переходить чисто на использование SQL однозначно не хочу. А Иначе как?

Конечно, могу сделать действительно универсальную структуру, когда отдельно есть таблица языков, а таблицы справочников представляют собой вместо набора полей для каждого языка одно поле с текстом, а другой - со ссылкой на язык. И выборка соответствующая - "взять значения для указанного языка, если нет, базовый (или рейтинг используемости языка)". Я такое уже делал. Универсальность, конечно, впечатляющая, но это перебор - для получения подобной инфы нужно или несколько запросов, или один, но длина его до тысячи и свыше символов - тоже лишняя нагрузка на БД. Так что избыточная универсальность ни к чему. Хотя, возможно, в некотором роде это стандарт.

Да не вижу, в том-то и дело ... так плохо - отсутствует динамика, делать универсально - гиморно, через пропертис - не вполне серьезно, да и работать с файловой системой минуя базу - несерьезно это (хотя, не скрою, быстро и удобно).

Что касается примера выше, представляющего "реляционную модель", то к такому варианту я не приходил - нормально ли это?