Любой, кто использует "проекты баз данных" в Visual Studio?

Ответ 1

Я использую проект базы данных, который является частью Visual Studio Database Edition. Это отличный инструмент. В основном вы определяете всю схему, создавая скрипты, которые затем проверяются в исходное управление. Затем он имеет встроенные инструменты для генерации разностных скриптов, которые, кстати, не удаляют данные.

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

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

Если у вас есть Team Studio - Team Suite или версия для разработки, вы можете использовать Database Edition.

Дайте ему попробовать и это отличная эволюция в развитии базы данных.

Ответ 2

Как и 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.

Ответ 3

Мы используем их. Мы сохраняем все наши схемы создания/обновления скриптов и хранимых процедур. Основная цель заключается в том, что мы можем подключить проект к SourceSafe или SVN.

Это простой способ контролировать версию скриптов SQL.

Это немного странно, пытаясь выполнить некоторое тестирование SQL в VS, но вы найдете способы обойти его.

Update

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

Ответ 4

Мы используем проект базы данных для обеспечения контроля версий для наших SQL-скриптов. Нам также нравится использовать среду Visual Studio для редактирования SQL; это немного легче использовать для некоторых из наших новых разработчиков, чем для анализатора запросов.

Ответ 5

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

• Если файл .dat в папке проекта db не синхронизируется с временным экземпляром базы данных, сравнение схемы даст неточные результаты. Не уверен, как это происходит, схема обзора тщательно сравнивает и удаляет ваш .dat файл (после закрытия решения), если что-то кажется неправильным.

• Если у вас есть 20 баз данных, они ссылаются друг на друга и используют круговые ссылки... Это будет больно. Я не понял, как сделать его масштабным для этого сценария. GDR 2, похоже, предлагает некоторые обещания.