Я работаю над требованием в 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. Или просто опубликуйте профили. Или используйте инструмент сравнения источников.
Основная идея состоит в том, чтобы сначала внести изменения в этот проект, а затем применить к вашим фактическим БД.
И, конечно, если у вас есть сборка сервера, часть этого решения может быть частью процесса сборки, и вы легко примените изменения к двум БД.
