Приветствую всех!
Передо мной стоит задача организовать сохранение исторических данных для существующей БД. Организация занимается арендой недвижимости.
Есть обычная БД(3НФ) которая содержит список текущих предожений.
Вся информация об объектах аренды содержится в основной таблице [Предложения] есть поле Дом(FK) , информация о его номере, местоположении разнесена на таблицы [Дома] , [Улицы] , [Районы] . Таким образом информация об адресе предложения получается запросом с JOINами из этих таблиц.

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

Комбинация может быть любая, и запрос должен иметь приемлемый таймаут.
Наверняка есть какие-то паттерны реализации подобного функционала.
Как я понял из теории, получается что сейчас есть только БД, а нужно смотреть в сторону понятий OLAP Data Warehouse или Data Mart. Или это это можно реализовать в рамках классической реляционной БД? Какие есть варианты? Спасибо!

Dimitry Sibiryakov,
Отлично, 3 новых понятия для изучения.
Может посоветуешь ссылку на ресурс с которого можно начать?

Dimitry Sibiryakov, я был бы очень признателен, если бы ты дал немного более развернутый ответ. Мне надо понять, с чего начать изучение данной тематики.

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

Dimitry Sibiryakov, записи из таблицы [Предложения] просто удаляются.
На другом форуме(ссылка в личке), мне посоветовали, что можно не удалять записи, а добавить столбцы
DateFrom и DateTo , записывать туда когда объект выставили, а когда сняли, таким образом все информация для истории сохранится.

Но если просто делать запросы для анализа истории цен к этой таблице, то опасаюсь следующего:
ЯОбъемы информации большие.
В базе в данный момент времени находится 300К объявлений.
Ежедневно она обновляется, возьмем 5% = 15К объявлений добавляется, столько же удаляется.
Таким образом за год будет ~ 5.5КК записей в таблице [Предложения] .
Таблица [Дома] содержит 140К записей.
Скажем, я хочу получить график динамики стоимости аренды 2х-комнатных квартир за 3 года с шагом один месяц.
Получается, необходимо 36 запросов к этой БД, каждый из которых должен посчитать среднюю стоимость за месяц, и не просто всех квартир, еще и удовлетворяющих некоторым условиям (2х-комнатные).
Я понимаю, что у меня не хватает фундаментальных знаний, и что способов реализации много, но хочу выбрать подходящий подход, чтобы не идти в неправильном направлении. Я уже начал читать про IndexedView's и хранимые агрегаты(как я понял, это хранимые процедуры с агрегатными функциями, гранулярность - что-то типа частоты с которой надо ими делать выборку).

Лички нет. В общем, на сайберфоруме тема.

Dimitry SibiryakovВот именно поэтому я и сказал сначала читать руководство по языку SQL, ибо "36 запросов"
это бред. Хотя, конечно, тоже вариант. Причём один из наибыстрейших.
=)) Буду изучать.
В общем, как я понял, надо оставлять все объявления, добавить период актуальности, а потом уже выбирать инструменты для выборки данных для аналитики. Например, вышеуказанные IndexedViews. Направление определено.
Благодарю за помощь!