Всем привет!

Есть класс Event:


Необходимо сохранять объекты класса Event в БД через Spring + Hibernate.

В каком виде лучше хранить данную сущность:?
1. Одна таблица Event, но тогда поле properties будет как BLOB.
2. Сделать две таблицы, отношение один ко многим. В 1-ой таблице id, во 2-ой id, key, value. Соответственно сначала добавляем запись в 1-ю, получаем id и записываем соответствующую запись в 2-ю таблицу.

Petro123Molasar,
Ты же уже спрашивал.
Хранить в бд не сущности бизнеса - глупость.

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

Petro123MolasarПро то, в каком виде хранить Properties, я не спрашивал.было тут про то как хранить мессаги в базе. Не твоё?
...
В базе хранят бизнес сущности - Паровоз, Выленки, Контрагент, ....
Но никак не Event, Handle, переменная, функция.
Понятно?

Мессаги моё)))) Но тут конкретно про таблицы и схему отношений.

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

Думаю, в моём случае нужно использовать две таблицы, чтобы можно было по полям key, value делать выборку данных.
BLOB - двоичный тип, доступа к значением полей нет. Получается нужно скачать всю БД в List<Event> и только потом обрабатывать данные. Что очень плохо)

Petro123MolasarМессаги моёссыль дай
https://www.sql.ru/forum/1311504/voprosy-po-activemq

Petro123Molasar,
Нужна отдельная база и писать нужно туда без тормозов т.к. событий миллион в минуту.
Аудит логов не относится к ИС?
Так и будет: выделенная машина под аудит и биллинг. Под типовые запросы на запись - хранимые процедуры.

Petro123вадя,
тебе повезло. В биллинге хибер не нужен.
А ты разве не знал, что хибер для CRUD.
Я планирую делать 2 реализации на Хибере и JDBC. Потом буду тестить под нагрузкой оба варианта. О результатах сообщу.

maytonMolasarВсем привет!

Есть класс Event:


Необходимо сохранять объекты класса Event в БД через Spring + Hibernate.

В каком виде лучше хранить данную сущность:?
1. Одна таблица Event, но тогда поле properties будет как BLOB.
2. Сделать две таблицы, отношение один ко многим. В 1-ой таблице id, во 2-ой id, key, value. Соответственно сначала добавляем запись в 1-ю, получаем id и записываем соответствующую запись в 2-ю таблицу.
Способ хранения может быть любым. В данном случае (1) и (2) правильные.

Но можно выбирать оптимальные стратегии хранения исходя из того как часто эти записи будут модифицироваться.
Например.

Вариант 1: Вся сущность event сериализируется в JSON и так и хранится в одной табличке. Как varchar.
Этот вариант хорош когда модификаций не будет. Место экономится. Или BLOB если varchar уже закончился
по размеру.

Вариант 2: Сущности properties (key,value) хранятся в отдельной табличке оптимизированной под частые изменения.
При этом получаем скорость обновления пропертей. Если конечно это необходимо. Расход места будет чуть больше.

И прочие варианты. Смешанные. Например если properties содержит в себе такие-же объекты properties (дерево) то
можно просто делать 1 табличку дерево где есть родительские и дочерние записи. Вобщем вариантов на самом деле еще
больше.

И поле id, я-бы сделал не враппером а примитивом. Всё таки id предполагает что это всегда NOT NULL.
В данном случае данные будут только добавляться в таблицу. Это что-то типа лога, журнала событий. В дальнейшем необходимо будет читать таблицу, делать выборку, поэтому вариант с одной таблицей и BLOB не подходит, т.к. для того чтобы что-то выбрать необходимо будет выкачивать всю базу, превращать BLOB в HashMap. JSON как varchar по этой причине тоже отпадает.