Николай,
попробую такой комментарий на ваш пост:
По части терминологии сорта "темпоральный", "битемпоральный"
и "правильного решения в рамках СУБД Oracle, к сожалению, не имеет", мое скромное мнение здесь стоит так:
эта опера другими словами поется.
В данном конкретном случае, речь идет всего лишь об ошибке в нормализации данных, допущенной разработчиком.
в задачах на получение "срезов" в
любом случае возникает join.
Соединение периода актуальности среза с собственно данными, относящимися к этому срезу.
Там, где он реализован через самосоединение вида
1.
2.
3.
4.
5.
6.
7.
8.
9.
Select t2.* From
(Select идентификатор_среза as geniuse_id, Max(дата_актуальности) as desired_date
From креативно_дефектная_таблица
Where
дата_актуальности <= :D
Group by идентификатор_среза) t1, креативно_дефектная_таблица t2
Where
t2.идентификатор_среза = t1.geniuse_id
And t2.дата_актуальности = t1.desired_date
он и выглядит нелепо и прямо является следствием допущенной ошибки проектирования.
И, также, нет сомнения, что виноват в этом
только Oracle.
Поскольку позволяет
невинному разработчику проектировать свои данные в эдаком стиле.
Ясно, что хорошая система так поступать не будет, и вовремя наставит ... разработчика на истинный путь.
Поскольку такие заходы встречаются чуть менее, чем повсеместно, простым пионэрством этого не объяснишь.
Имхо, в 10 случаях из 10 это является следствием того, что никакого "первого" или "последнего" среза в первоначальном дизайне просто не было.
Понимание и потребность в истории срезов пришла потом - по мере развития системы.
И выбран конкретный вариант как наименее затратный в смысле количества штук изменений, вносимых а архитектуру системы для минимально работоспособной реализации.
Так технический дефект заливается бетоном, превращаясь архитектуру, на примере которой следующие поколения пионэров
обучаются истинно правоверному би-темпоральному проектированию, одновременно с усвоением знаний о том, чего не может Oracle.
