Как отобразить таблицы поиска в Hibernate для полустатических данных - PullRequest
Новая
       16

Как отобразить таблицы поиска в Hibernate для полустатических данных

3 голосов
/ 28 июня 2011

Я имею дело с существующей таблицей событий: 

Event Table:
id    event_type          status    ...
==    ==========          ======
 1    high.temperature    ACCEPTED
 2    missing.invoice     WAITING
 3    missing.invoice     WAITING

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

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

Что я хочу, это примерно так: 

Event Table:
id    event_type    status   ...
==    ==========    ======
 1    223           3
 2    245           4
 3    245           4

EventType Table:
event_type    name  
==========    ================  
223           high.temperature
245           missing.invoice

Мой вопрос: есть ли способ автоматизировать вставки и выбор в / из таблицы поиска , чтобы мне не нужно было определять класс Java для EventType ии искать соответствующий EventType каждый раз, когда я вставляю в событие?Что касается Java, я бы предпочел рассматривать event_type как простую строку, как сейчас.

1 Ответ

3 голосов
/ 29 июня 2011

Операции чтения не должны вызывать каких-либо проблем: создайте сущность EventType, добавьте частное, многократно извлеченное отношение «многие к одному» между Event и EventType, поместите EventType в кэш второго уровняи добавьте метод получения, возвращающий имя типа события в Event.Это делает его прозрачным для остальной части приложения и не вызывает дополнительных выборок благодаря кэш-памяти второго уровня.

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

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

...