SQL Server: реплицировать изменения схемы в другую базу данных

Я работаю над требованием в ASP.NET Web API, которому нужны две идентичные базы данных.

Я создал две идентичные базы данных на одном сервере. Скажем, один из них предназначен для разработки, а другой для тестирования.

Я хочу реплицировать всю схему (например, хранимую процедуру, представление и таблицу), мгновенно меняющуюся из одной базы данных в другую.

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

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

Я прошу вас рассказать мне, если это возможно, или если есть другой подход к достижению этого

Ответ 1

Для меня это не похоже на хорошую идею.

Если вы внесете изменения в среду разработки, которая разбивает систему, вы сразу же нарушите среду тестирования. Это было бы плохо.

Если вы внесете изменение кода в среду разработки и сделаете изменения базы данных для его поддержки, если смена базы данных будет немедленно реплицирована, у вас будет код и база данных, которые не синхронизированы, и, возможно, тестовой среды.

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

Вы можете использовать схему Visual Studio для сравнения изменений структуры базы данных в рамках вашего проекта

Ответ 2

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

Контроль источника имеет все виды положительных воздействий и должен стать привычкой. Даже для ваших баз данных.

Я предлагаю использовать Liquibase из-за того, что он является свободным открытым исходным кодом и довольно гибким.

Ответ 3

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

Вы вносите изменения в код на обоих БД? Если у вас есть отношение "ведущий-ведомый", вам нужно только инициализировать подчиненную БД. В противном случае, в случае мастера-мастера, вы должны придерживаться своего рода версии.

Ответ 4

Одним из возможных (родных) решений является включение транзакционной репликации (только для DDL-изменений)

https://docs.microsoft.com/en-us/sql/relational-databases/replication/publish/make-schema-changes-on-publication-databases

У вас есть возможность иметь несколько баз данных (подписчиков) и переносить подписчиков на другие серверы в будущем (при необходимости).

Другим решением является использование некоторых сторонних инструментов, таких как PS + ApexSQL Diff: https://solutioncenter.apexsql.com/how-to-automatically-keep-two-sql-server-database-schemas-in-sync/

или SQL Deltap >

или SQL Compare (Красные ворота)

Ответ 5

Я предлагаю вам использовать специальное решение от Microsoft. Инструменты данных SQL Server для Visual Studio. Это добавит новый тип проекта в ваши шаблоны Visual Studio и его можно будет использовать (возможно, вы даже его уже установили).

Этот тип проекта будет содержать всю схему БД и все процедуры/функции/триггеры.

Так как это проект, он может быть частью вашего решения, и вы можете хранить все изменения истории базы данных в системе управления версиями (Git, SNV, TFS и т.д.).

Чтобы применить изменения к своей второй БД, есть отдельные способы сделать это. Вы можете использовать файловый подход .dacpac. Или просто опубликуйте профили. Или используйте инструмент сравнения источников.

Основная идея состоит в том, чтобы сначала внести изменения в этот проект, а затем применить к вашим фактическим БД.

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