Недавно я попробовал (версия SQL 2008), и я нашел их вполне в порядке. Единственная проблема заключается в том, что мастер недостаточно интеллектуальный, чтобы обновлять структуру базы данных без предварительного удаления всех данных. Именно поэтому эти проекты не используются на практике?
На самом деле никогда не видел, чтобы кто-нибудь их использовал или вообще упоминал о них. Также ничего не видно в блогах и форумах, если вы явно не ищете его.
Что с ними не так?
Я использую проект базы данных, который является частью Visual Studio Database Edition. Это отличный инструмент. В основном вы определяете всю схему, создавая скрипты, которые затем проверяются в исходное управление. Затем он имеет встроенные инструменты для генерации разностных скриптов, которые, кстати, не удаляют данные.
Он также имеет инструменты сравнения данных, поэтому вы можете сравнивать данные между базой данных и генерировать script, чтобы сделать базы данных одинаковыми.
В недавнем выпуске GDR есть некоторые интересные функции, добавленные к нему. Так что, если вы используете встроенный метод развертывания, вы можете создать пакет развертывания, который при запуске будет анализировать целевую базу данных и применять только различия.
Если у вас есть Team Studio - Team Suite или версия для разработки, вы можете использовать Database Edition.
Дайте ему попробовать и это отличная эволюция в развитии базы данных.
Как и Glennular, мы используем их для контроля версий нашей схемы и s'procs.
Несмотря на то, что у нас есть довольно продвинутая структура управления версиями (CI, автоматическое развертывание для dev, развертывание с одним кликом для стадии и prod); мы не включаем ни один из проектов БД в эту структуру. Мы просто пока не верим.
ОБНОВЛЕНИЕ: (для Out In Space)
У нас есть отдельные проекты TFS для функциональных областей компании (Sales, Marketing и т.д.). В рамках каждого проекта TFS у нас есть папка Main и Production. У нас также есть один проект TFS, который содержит проекты базы данных, и другой, который содержит проекты Common assembly/projects studio.
После выпуска мы переходим от Main to Production. У нас нет промежуточной ветки, поскольку мы слишком быстро двигаемся, чтобы справиться с этим. Правильно или неправильно, наша производительность измеряется частично количеством выпусков производственного уровня, которые мы делаем в неделю; исправления ошибок, новые функции и т.д.
CI настраивается на главном ветки, так что каждая проверка вызывает развертывание сервера сборки в наших средах DEV. Затем запускаются тесты на устройства и веб-сайты, а качество сборки автоматически устанавливается на "Разработка", если оно завершается успешно. Когда кто-то изменяет качество сборки на "В стадии постановки", это приводит к тому, что любые предыдущие сборки "В стадии постановки" должны быть установлены на "Отклонено" и заставляют эту сборку перенаправляться на наши промежуточные серверы при обновлении файлов конфигурации, чтобы указать на правильные серверы. (Для этого я использовал сценарии TFS Deployer и PowerShell).
QA проводит тестирование на наших промежуточных серверах. После того, как они счастливы, производственная группа меняет качество сборки на "Производство". Это приводит к отправке сборки в область производства, которая затем вручную копируется в нужное место. После завершения, производство уведомляет разработчиков, которые затем передают эту версию в папку "Производство". QA также уведомляется о том, кто затем проводит тесты на производство, чтобы убедиться, что все действительно работает так, как ожидалось.
У нас есть отчеты, созданные для того, чтобы показать нам, какие изменения существуют между производственными выпусками, чтобы мы знали каждую проверку в том, что она развертывается. Это предотвращает появление неизвестных сообщений, таких как изменение базы данных и т.д., Или какой-либо другой потенциально нарушающий код.
Кроме того, наш BA отслеживает рабочие элементы через Team System Web Access и знает, когда эти элементы находятся в производстве.
Хотя наш DBA использует Database Edition (GDR), они не впечатлены уровнем контроля для автоматического развертывания. Я надеюсь, что Rosario привнесет в линейку продуктов лучший контроль над развертыванием; но до тех пор мы имеем TFS Deployer и powershell.
Мы используем их. Мы сохраняем все наши схемы создания/обновления скриптов и хранимых процедур. Основная цель заключается в том, что мы можем подключить проект к SourceSafe или SVN.
Это простой способ контролировать версию скриптов SQL.
Это немного странно, пытаясь выполнить некоторое тестирование SQL в VS, но вы найдете способы обойти его.
Update
Мы действительно встроили его в наши сценарии развертывания, наш инструмент развертывания, проходит через проект БД (кроме флаговых папок) и запускает все script. Мы просто создали быстрый инструмент для запуска проекта. Если у кого-то есть другие решения для развертывания проекта БД, который был бы полезен.
Мы используем проект базы данных для обеспечения контроля версий для наших SQL-скриптов. Нам также нравится использовать среду Visual Studio для редактирования SQL; это немного легче использовать для некоторых из наших новых разработчиков, чем для анализатора запросов.
Я использовал их в нескольких платных проектах, и я думаю, что это отличный инструмент. Thats сказал, я видел некоторые проблемы.
Если файл .dat в папке проекта db не синхронизируется с временным экземпляром базы данных, сравнение схемы даст неточные результаты. Не уверен, как это происходит, схема обзора тщательно сравнивает и удаляет ваш .dat файл (после закрытия решения), если что-то кажется неправильным.
Если у вас есть 20 баз данных, они ссылаются друг на друга и используют круговые ссылки... Это будет больно. Я не понял, как сделать его масштабным для этого сценария. GDR 2, похоже, предлагает некоторые обещания.