Структура данных Java для использования с Hibernate для хранения неизвестного количества параметров?

Question

Следующая проблема: я хочу сделать поток новостей коротких сообщений на основе локализованных текстов. В разных местах этих сообщений я должен вставить параметры, чтобы «настроить» их. Я думаю, вы понимаете, о чем я;)

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

• создайте объединенную строку и сохраните ее как таковую (я думаю, уродливо и трудно поддерживать)
• сделайте некоторую причудливую нормализацию и сделайте каждый параметр отдельной строкой в ​​базе данных (думаю, чисто, но это кошмар производительности)
• Поместите параметры в Array, Map или другую структуру данных Java и сохраните их в двоичном формате (вероятно, это приведет к большим накладным расходам по размеру)

Я склоняюсь к варианту № 3, но боюсь, что он может быть дорогостоящим с точки зрения размера в базе данных. Что ты думаешь?

Answer 1

Если вы можете позволить себе снижение производительности при использовании нормализованного подхода с отдельной таблицей, я бы пошел с этим подходом. Мы используем тот же подход, что и ваше первое предложение на работе, и оно становится грязным , особенно когда вы достигнете предела столбца и ключ / значения начнут усекаться!

Answer 2

Это зависит немного. Является ли количество параметров огромным для каждого объекта? Если это не вероятно, второй вариант является лучшим.

Если вы не хотите добавлять дополнительные запросы, вызванные отложенной загрузкой, вы всегда можете изменить тип выборки для переменного числа параметров, которые добавят только одно объединение к запросу, который вы всегда выполняли. В нормальных условиях это не большая цена.

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

Answer 3

сделать нормализацию. Я бы предложил что-то вроде:

Таблица сообщений ID

Параметры таблицы message_id ключ значение

Хранение сериализованных объектов Java в базе данных в большинстве случаев является довольно плохой вещью. Поскольку их сложно поддерживать, и вы не можете получить к ним доступ с помощью «простых» инструментов SQL.

Влияние на производительность не так велико, так как вы можете собрать все вместе за один выбор, используя соединение.

Answer 4

напрямую поместите его как строку и сохраните ..