Мы разрабатываем модуль отчетности для нашего программного обеспечения, и поэтому нам необходимо переместить некоторые данные из производственной базы данных системы в базу данных хранилища данных, которая будет использоваться в качестве источника данных для отчетов (отчеты SQL Server).
Схема в рабочей БД довольно старая, поэтому, как только у нас появятся данные в БД DW, нам потребуются некоторые дополнительные поля (например, вычисление правильного столбца даты и времени из целых столбцов «дата» и «время» в рабочей базе данных). (Не спрашивайте, он старый.)
Мы внутри обсуждаем, как это сделать эффективно. Прямо сейчас это реализовано в ужасном задании SSIS, которое в основном разрывает всю базу данных DW каждую ночь и снова создает ее из prod db, выполняя преобразования данных по ходу дела. Это не очень хорошо масштабируется.
Я изучал использование «более новых» технологий, таких как, например, репликация SQL Server для более детального перемещения данных.
Мои вопросы по этому поводу: - С репликацией часть «перемещения данных», очевидно, решена, но не часть преобразования данных. Я знаю, что могу создавать триггеры обновления в базе данных DW, но все триггеры, связанные с таблицами, похоже, стираются всякий раз, когда я выполняю повторную инициализацию подписки, что затрудняет настройку.
Я не ищу здесь точного ответа, скорее намек на то, в каком направлении двигаться. Извините, если вопрос немного размыт.
обновление: спасибо за хорошие замечания ниже. Это программное обеспечение, которое мы продаем клиентам, поэтому я большой сторонник того, чтобы у клиента было как можно меньше «элементов конфигурации», которые он мог бы настроить и поддерживать. Пакет SSIS в его нынешнем виде является еще одним «элементом», за которым заказчик должен следить, наряду с его графиками.
Репликация заинтриговала меня, потому что она полностью абстрагирует всю «дилемму» CRUD при перемещении данных, но вы можете быть правы — SSIS все равно будет лучше, если логика SSIS создана немного умнее, чем сегодня.
Данные могут быть довольно большими, поэтому стирание и повторный импорт всего, что мы делаем сегодня, определенно является проблемой, требующей решения.
