Мы используем Red Gate для сравнения текущей схемы с файлами сценариев, хранящимися в SVN, для базовых показателей, версий и т. д.

Однако наш эталонный эталон на самом деле является восстановленной копией производства. Это наш базовый уровень, и он должен соответствовать SVN. Частью процесса развертывания является передача основных сценариев в SVN, что Red Gate делает с пользой: он только изменяет файлы для измененных объектов.

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

Управление исходным кодом базы данных — это хорошо, но его сложно реализовать из-за того, что представляет собой объект SQL Server: строка или 3 в некоторых таблицах...

на очень упрощенном уровне вы можете написать службу Windows, которая следит за файловой системой и анализирует файлы в каталоге aprticuler и применяет их к базе данных. Аналогичный мехинсим с использованием брокера SQL-сервера (или просто триггеров и xp_commandshell) можно использовать для написания обратного.

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

ShiftSchema использует триггеры базы данных для синхронизации объектов базы данных SQL Server 2005 и 2008 с файлами на диске, которые подходят для хранения в системе контроля версий. Он также отслеживает изменения в файловой системе (когда вы обновляетесь из репозитория и получаете изменения схемы, зафиксированные другим разработчиком) и отправляет эти изменения в вашу личную базу данных разработки.

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

Он также имеет средство для сравнения двух баз данных (либо в СУБД, либо на диске) и создания сценария DDL для их синхронизации.

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

Если вам интересно, ссылка на сайт в моем профиле указывает на сайт ShiftSchema.

Red Gate создает систему управления версиями SQL, интегрируя ее с SSMS, чтобы обеспечить как фиксацию, так и извлечение из системы управления версиями (в фоновом режиме мы связываем объекты базы данных с соответствующими файлами создания SQL, хранящимися в системе управления версиями). Хотя мы рекомендуем, чтобы каждый разработчик использовал собственную разрабатываемую копию базы данных, мы планируем поддерживать модель, в соответствии с которой она является общей, хотя это имеет недостаток, заключающийся в том, что любой разработчик может сломать базу данных для всех в любой момент.

Мы надеемся выпустить инструмент в первой половине 2010 года. Если вы хотите узнать больше или зарегистрироваться в нашей программе раннего доступа, перейдите по следующей ссылке:

http://www.red-gate.com/products/SQL_Source_Control/index.htm

С уважением,

Дэвид Аткинсон, менеджер по продукту, Red Gate Software

что касается изменений, внесенных непосредственно в SQL-сервер другими пользователями: я не знаю, насколько это практично для вас, но может быть хорошей идеей вносить ВСЕ изменения с помощью сценариев SQL, а не индивидуально, непосредственно на сервере. Эти сценарии SQL можно пронумеровать и поместить в систему управления версиями по вашему выбору. Чтобы получить более точный контроль над развернутыми изменениями, вы можете использовать сценарий каждого изменения вместе со сценарием отката, который можно использовать при необходимости.

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

Вам обязательно нужно отслеживать КАЖДОЕ изменение, внесенное в объект, или только последнее? Мы написали решение на C#, которое работает против TFS, поскольку у нас есть базовый уровень всех объектов SQL в базе данных, а затем, используя методы из Microsoft.SqlServer.Management.Smo, мы просто просматриваем каждый объект базы данных и сравниваем «рабочий набор». ' к серверной версии. Мы запускаем его ночью как часть нашей вечерней обработки, и для прохождения всего сервера из 9 баз данных требуется около 15 минут. Мы обнаружили, что он отлично работает, не требует прямого изменения серверов/баз данных SQL и работает для SQL 2005/2008. Он создает отчет, который отправляется администратору нашей базы данных по почте, сообщая им, какие объекты изменились, а затем позволяет им пройти через TFS и посмотреть, что к чему.

Я изначально начал здесь; http://odetocode.com/blogs/scott/archive/2008/02/02/versioning-databases-change-scripts.aspx

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

С уважением.