исходные данные: есть огромная таблица items(customer,item,start_date,end_date,...<прочие атрибуты>) - получаем таблицу с текущими и историческими данными, историческими данными обычно активно интересуются не более недели(пока выставили счёт, пока он дошёл и тп... позже тоже бывает интересуются, но реже), отношение customer к item - один ко многим, удалений в таблице не бывает, запросы бывают много чаще чем апдейты+добавление... для получения списка item's приминяются запросы вида select * from items where customer=<customer> and <date of search> between start_date and end_date, где <date of search> - практически всегда попадает в интервал sysdate-1/24... сейчас система стала заметно подтормаживать, пытаюсь решить проблему, есть несколько вариантов, хотелось бы услышать мнение

1) сеционировать по диапазону на 2 партиции: устаревшие(end_date less than <дата на месяц меньше текущей>), текущие остальные... и раз в N месяцев запускать по расписанию скрипт выделяющий из текущей партиции записи закрытые более месяца назад и переводящий их в устаревшую партицию(тут надо поподробней посмотреть в возможности oracl'a, напрмер похоже придётся пересобирать индексы)
2) создать механизм(через тригеры или по расписанию, или через процедуры работы с базовой таблицей) - который будет на каждое изменение таблицы items, вносить изменения и в денормализованую таблицу items_current(customer, items<список item'ов через запятую>, start_date<максимальное значение start_date для всех item'ов даного customer>, end_date<null>), при запросах искать в начале в таб items_current и только если не найдутся необходимые данные(дата поиска < start_date или дата поиска > даты последнего обновления если обновление по расписанию)
3) вариация 2)... хранить не 1 запись для каждого customer, а набор записей например за месяц тогда кол-во "непопавших" записей можно считать равным 0

softwarer alecseyесть несколько вариантов, хотелось бы услышать мнение
Приведенные варианты показывают, что Вам стоит сначала прочитать Кайта, а уж потом садиться реализовывать БД.
Оба варианта нормальны в своей ситуации, но если делать их по-человечески. Первый - просто обычный range partition по дате, без извращений. Второй - materialized view + query rewrite (тут сходу не уверен, что query rewrite легко и непринужденно заюзается - надо смотреть)
Спасибо за критику, но
1) это не извращение, а движущееся окно, у кайта описывалось если не ошибаюсь ;)
2) materialized view - смотрел в эту сторону, не совсем подходит, complite refresh будет занимать слишком много времени