OK, 
Есть два Еntity. (см. Picture 1.png). Customer упрощён.
У Customer дольжен содержаться его тип, но только последний (я его назвал effectiveCustomerType), а не вся цепочка.

effectiveCustomerType должен определяться таким образом:
1. Customer.customerTypeId == CustomerType.id
2. CustomerType.effectiveDate <= (настоящее время)
3. CustomerType.expirationDate == null; или > (настоящее время)

Добавлено через 1 минуту и 6 секунд
кстати, CustomerType.effectiveDate тоже PK.

Присоединённый файл ( Кол-во скачиваний: 5 )
 Picture_1.png 17,97 Kb

И опять я вмешаюсь в вашу дискуссию. 
У меня что-то подобное есть, так опять таки такая задача решена на уровне базы.
Все сущности хранятся в одной таблицы. Версии хранятся по принципу следующий-предыдущий + поле даты, когда была изменена сущность.
Соответственно первая версия не имеет предшественника (форин кей на предудую версию), последняя версия не имеет "последовательника"
(форин кей на следующую версию).

Зачем что-то выдумывать в java на уровне ORM, если можно по простому на уровне базы, а в java просто реализовать логику реализации этой версионности 

Что бы по минимому писать SQL запросы, и по максимому пользоваться тем что даёт mapping в JPA.

Добавлено через 2 минуты и 23 секунды
Более того, каким образом в моделе которую ты предлогаешь, будет сделан Mapping сущностей? 
Проблемма то таже. И она никак не в дата модели...

Если переносимость не важна, то можно и такие варианты рассмотреть. Правда процесс установки приложения будет немного сложнее за счет дополнительно конфигурации БД.

Добавлено через 11 минут и 8 секунд

А что за цепочка?
Я так понимаю, что каждый CustomerType должен быть связан с неким Customer, но при этом, каждый Customer имеет ссылку на эффективый, т.е. удовлетворяющий неким условиям, CustomerType?

Так условия вот такие:


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

Ну или опять же нужно найти способ получить последнюю версию, то есть так или иначе нужна проверка этой самой версии.

Добавлено через 1 минуту и 15 секунд
Как таковой однозначной ссылки на CuatomerType у Customer нету.

В ресультате таблица ЦustomerType может выглядеть так:


Присоединённый файл ( Кол-во скачиваний: 9 )
 Picture_2.png 19,85 Kb

Мне кажется нужно делать поиск CustomerType запросом. Без лишних мапингов. Просто пока не вижу причин извращаться.

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

Добавлено через 49 секунд
Ну или может ещё какие идеи будут?

Или ещё проще:
Вытаскивать все типы относящиеся к Customer, а логикой уже выберать тот который нужно. Но опять же это трата.

Нашёл решение.
Поделюсь как только отлажу.

Отлично. Выкладывай. 

ага, мне тоже интересно...

Значит так. 
Я расскажу весь свой ход мыслей и к хему я пришёл в резултате.

Не буду углубляться в саму проблемму (цм. выше), но суть в том что нужно организовать сохранение истории той или иной сущности при этом оставляя возможность relationship mapping (или поиск) по id сущностий

Базовая требуемая сущность такова:


В JPA существует такая вещь как Inheritance при этом нескольких типов:
- TABLE_PER_CLASS
- JOINED
- SINGLE_TABLE

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

SINGLE_TABLE
SINGLE_TABLE выглядет самый экономный и быстрый способ.
для этого нужно добавить ещё одны колонку hist TINYINT(1) хто бы воспользоваться ей как discriminator по типу integer.
создать два класса:



В классе CustomerTypeHist @Id должен задаваться а не генерироваться, потому что id CustomerTypeHist должен оставаться таким же как и в CustomerType, что бы Customer мог их всех найти. (! проблемма номер раз, нужно превратить ключ в Composit, добавив в него на пример effectiveDate )
А если такое дело ты нихего мы этим не добились и никак не воспользоваться тем что даёт JPA, а нужно гонять запрос ручками.
Не хотим!!!

Остаётся TABLE_PER_CLASS
Во вот это то что нам нужно!!! делаем две таблисы:


Два класса:




Теперь Customer может смотреть на CustomerType у которого только одна возможная копия для него, а с историей мы уж как то разберёмся.

Вроде как всё, но не тут то было: TABLE_PER_CLASS не поддержинается в TopLink!!! дасадно!

*Кстати этот вариант я не проверял, так как работаю с TopLink. Если кто проверит расскажите. 

Ничего из вешеописанных не приблежается к решению.

Но есть ещё вариант: нам не обязательно брать Inheritance от Entity.

Делаем следующее:
Таблицы:


И на этот раз 3 класса:






Дело в том что на этот раз мы берём только общую структуру у CustomerTypeSuper, а на таблицы завязываем уже сами сущности, которые друг с другом связаны только косвенно.
в таблице CustomerType остаются по одной копии на каждый id тыпа (с одним PK).
CustomerTypeHist recId превращается в PK, a по id мы можем найти всю историю изменений CustomerType с такимже id.

Типичный результат таков:
CustomerType


CustomerTypeHist


Ну вот вроде и всё.

Теслировал через Bean.

Добавлено через 4 минуты и 52 секунды
А если не хочется писать по 3 класса на каждую сущность, то MappedSuperclass можно превратить во что то более абстрактное, что подходит для всех сущностей которым нужно сохранение истории, и пользоваться им где надо.

P.S. Любые поправки и предложения с радостью принимаются.
   

Это сообщение отредактировал(а) ShurikA - 9.1.2009, 04:07

Осталось ещё кое что сделать:
надо бы это дело автоматизировать. Я просто не нащёл путь сделать Dependency Injection в Entity, но идя в том что бы в @PreUpdate сущность сама записывала историю.

Как это сделать?