Как синхронизировать базу кода и схему базы данных?

Question

Итак, недавно над проектом, над которым я работаю, мы изо всех сил пытались синхронизировать базу кода решения и связанную схему базы данных (Database = SQL Server 2008).

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

Мы не используем VSTS: Database Edition (DataDude), но стандартный проект базы данных Visual Studio со сценарием (пакетным файлом), который разрушает и воссоздает базу данных из сценариев T-SQL. Это решение .Net & ASP.net с LINQ to SQL, лежащим в основе ORM.

У кого-нибудь есть идеи по подходу (автоматизированному или нет), который будет держать всех в курсе новейшей схемы базы данных?

Непрерывная интеграция с MSBuild является опцией, но она помогает только зафиксировать любые внесенные критические изменения, но не помогает в сценарии, который я выделил выше.

Мы используем Team Foundation Server, если это поможет ..

Answer 1

Мы пытаемся работать дальше от сценариев создания.

Т.е. изменение базы данных не разрешено, если скрипт не был протестирован и проверен в системе контроля версий.

Но это предполагает, что команда базы данных интегрирована с вашей командой приложений, чего обычно не бывает в большом проекте ...

(мне хотелось ответить на это "с большим трудом")

РЕДАКТИРОВАТЬ: Инструменты не помогут вам, если ваш процесс не так.

Answer 2

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

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

Answer 3

взгляните на DB Ghost - вы можете создать dbp с помощью скрипта за считанные секунды, а затем управлять всем кодом вашей базы данных с помощью менеджера изменений. www.dbghost.com

Это именно то, для чего была разработана DB Ghost.

Answer 4

Мое решение этой проблемы простое. Определите все как XML и убедитесь, что база данных, ORM и пользовательский интерфейс генерируются из этого XML, без исключений. Таким образом, вы можете использовать инструменты генерации кода для быстрой регенерации скрипта создания базы данных, который изменит вашу схему, сохраняя при этом (надеюсь) некоторые данные. Требуется некоторое усилие, но чистый результат того стоит.

Answer 5

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

Answer 6

Используйте инструмент, подобный RedGate SQL Compare , чтобы сгенерировать схему изменений между любой заданной версией базы данных. Затем вы можете проверить этот файл в исходном коде

Answer 7

Если вы не используете Visual Studio Database Professional Edition, то вам понадобится другой инструмент, который может разбить базу данных на ее элементарные части, чтобы их было проще в управлении и замене.

Я бы порекомендовал всерьез рассмотреть средства SQL Redgate , если вы хотите поддерживать разумность всех изменений и обновлений вашей базы данных.

• SQL Packager
• SQL Multi Script
• SQL Refactor

Answer 8

Мы в основном поступаем так, как вы, со скриптом генерации, который также включен в систему контроля версий. Я назначенный хозяин базы данных, поэтому все изменения в самом скрипте делаются через меня. Люди присылают мне сценарии изменений, которые они внесли, я обновляю свою главную копию схемы, запускаю сценарии генерации (SSMS) для создания нового сценария БД и затем проверяю его. Я сохраняю свою копию кода с любым изменения, которые делаются в другом месте. Мы небольшой магазин, так что у нас это хорошо работает. Я понимаю, что это, вероятно, не масштабируется.