Добрый день!

Вопрос больше архитектурный, сейчас в рамках департамента - есть база, в ней хранятся данные, алгоритмы , расчеты (хранимые процедуры на стороне сервера). Данные отображаются для пользователей с помощью репортинга по http.
В будущем возможно построение централизованного хранилища данных.
Соответственно возникает вопрос, как правильно поступить с текущей базой и алгоритмами?:
1) Оставить данные и алгоритмы в текущей базе и ежедневно подливать данные из хранилища (сейчас льются из разных источников).
2) Переделывать алгоритмы и расчета на обращение к данным хранилища.
3) Перенести расчеты и алгоритмы в хранилище/витрину данных и визуализировать отчеты прямо оттуда?

Если у кого есть опыт, поделитесь вашим подходом к организации процесса...

Прозвучало как сарказм...
Моя база описывает процессы одного бизнес подразделения, в будущем может появиться база/хранилище - которое должно содержать данные всех бизнесов (в том числе и мои справочные данные)...

Не всегда. Иногда для нужд репортинга удобно подготавливать данные в отдельных таблицах или даже БД.
Там делать все нужные расчеты и преобразования.

Самые популярные преобразования: отсечение времени от даты и конкатенция неск. тхт-полей в одно.
Вы за первый из предложенных мной вариантов или другое?

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

Давайте добавим конкретики. Пусть есть страховая компания в ней есть например ДМС и автострахование. Пусть в каждом бизнесе есть своя программа, уж очень они разные и в одну впихнуть логику не получается, соответственно разные СУБД.
Для обеих программ нужен справочник КЛАДР , можно в каждую программу качать по утру его отдельно(обновления) с сервиса/cайта и т.д. Но можно закачать в единое , центролизованное хранилище (витрину) и уже обеим программам брать справочник из dwh. А можно пойти дальше - все данные из СУБД (дмс и автострахование) по ночам сливать в это хранилище, например клиент он и там и там клиент, далее управленческие отчеты уже строить на базе хранилища. Профитом опять же будет централизация данных и уменьшение нагрузки в виде отчетов на базы бизнесов .
Посему и спрашиваю про ваш аналогичный опыт, про ваши решения, дабы по-максимому избежать ошибок...

Спасибо за ссылки , а там "война план покажет" - может привести к архитектурным просчетам и клепание костылей в будущем, такой подход считаю в корне не верным, извините!

Хмм, я то по своей наивности думал, что сначала алгоритмы и ТЗ, а потом уже выбор инструментов для реализации.
По вашему, когда специалист выбирает какую базу выбирать для своей задачи, то он должен посмотреть на Sql Management Studio или на Oracle Sql Developer, посмотреть, что удобней - ту и базу выбрать. :-)
Весьма странное решение, имхо...

Думаю, порядка 300 ГБ суммарно. Самые большие таблицы , их не много и до 100 млн строк. В среднем в таблицах порядка 100 тыс строк. Прирост в справочниках небольшой, если складировать первичку, то тут может быть до 500 Мб в день данных.
За хайпом и модой погони нет, тут вы правы!

Хммм, у вас фенечка такая бросать общие, завуалированные фразы ни о чем? Это для самоутверждения что ли? :-)

Можно было и по русски написать - делайте витрину данных своими силами и берите данные в свои системы оттуда по необходимости.
Схема забора данных, не через шину, а точка-точка.

Действительно, потянет офисный комп хранилище, если к нему часто будут обращаться, а как же быстродействие и надёжность?
Вы даже SSD диск не посоветовали и что будет c хранилищем, если у этого обычного компа винт ночью накроется или материнка полетит?
Мдеее, вот реально иногда после некоторых советов - жалеешь что спрашивал! :-(

Пожалуй самое интересное мнение и ответ, спасибо вам за вашу дележку опытом!