Я считаю, что обработка перемещения данных в проектах SSDT может быть очень трудной для понимания, и это часто является источником ошибок и неудачных развертываний. Нам нужно обслуживать развертывание в пустой базе данных, где нет объектов, в базе данных со старой схемой, и в RDS, где мы размещаем наши базы данных, у нас были проблемы, из-за которых у нас при развертывании не было автоматического удаления объектов, удаленных из проекта. Поэтому нам даже нужно разрешить объекты, которые до сих пор не были очищены (хотя мы ищем изменения, которые позволят нам включить автоматическое удаление).
Я думаю, что сценарии до и после развертывания обычно позволяют нам обрабатывать все перемещения данных, которые нам требуются, но четкий обзор порядка, в котором объекты создаются и включаются во время развертывания, поможет правильно настроить сценарии. в первый раз.
Вот несколько примеров того, что мне интересно понять.
- Когда оценивается схема целевой базы данных? До выполнения сценария предварительного развертывания?
- Когда создаются различные типы ограничений (проверка, уникальный, внешний ключ и т. Д.)? Когда они включены?
- Какое влияние оказывают рефакторинги в журнале refactorlog?
- Как использовать умные настройки по умолчанию для улучшения / упрощения сценариев развертывания?
- Как эти знания лучше всего применять для решения некоторых общих проблем?
- Добавить новый столбец с уникальным ограничением.
- Переместить данные из заменяемой таблицы в замену.
- 1022 * Etc. *
- Есть ли альтернатива использованию динамического SQL в операторах exec? Мы делаем это для сценариев, которые должны запускаться, если, например, объект уже завершен. Если объект не существует, то сценарий выдает ошибку.
- Существует ли какой-либо механизм, который мы можем использовать для внесения изменений до оценки схемы целевой базы данных? Сценарий предварительного развертывания кажется слишком поздно?