Данные управления исходным кодом RedGate SQL

Question

Я изучаю инструмент SQL Toolbelt RedGate, чтобы обеспечить полную базу данных CI, и мне удобно, как инструменты могут облегчить мои потребности в схеме и статических данных.

Однако в других таблицах будет определенное количество данных, которые я хотел бы использовать для управления исходным кодом и использовать его в своем CI. В этих таблицах может быть миллион записей с только несколькими учетными записями, которые должны находиться в контроле источника. Конструкция базы данных означает, что эти данные не могут находиться в отдельной таблице, которая затем может контролироваться источником.

Хорошим примером может служить таблица «Пользователи», в которой вы хотите, чтобы источник контролировал пользователя Admin или System, чтобы он мог быть частью вашего CI, но хотите исключить любых реальных пользователей.

С середины 2011 года у RedGate был request for filtered static data, и мне было интересно, разработал ли кто-нибудь разумный метод преодоления этого ограничения?

Answer 1

Я пробовал решение с использованием сценариев миграции, но порядок их выполнения все еще вызывал проблемы.

Решение, которое я выбрал, в конце концов состояло в том, чтобы иметь отдельную базу данных, связанную с источником управления, со всеми таблицами, которые содержат системные данные или смешанные данные, чтобы контролировать их записи.

Затем я разрабатываю в другой базе данных и вставляю схемы и данные в базу данных, контролируемую источником, для их фиксации. Таким образом, таблицы данных, управляемые источником, никогда не содержат «пользовательских» данных.

Я обнаружил, что командам автоматизации DLM не хватает функций и вместо этого выбрал запуск SQL Compare и SQL Data Compare с помощью командной строки для выполнения нашего CI. Это не было без случайной икоты, но они решаются с использованием вышеупомянутых инструментов и вручную выталкивают из SC в нашу базу данных CI.

Answer 2

Все, что я могу думать, было бы:

1. Есть две таблицы
2. Один для случайных пользователей
3. Один для супер-пользователей, которые вы хотите иметь как статические данные
4. Commit просто супер пользователей таблица данных для управления источником
5. Создайте представление, которое будет UNION ALL обе эти таблицы
6. Используйте этот вид вместо фактические таблицы в вашем коде.

Возможно, это не самый красивый способ сделать это, но я думаю, что он должен работать для вашего прецедента.