Почему я должен использовать Visual Studio 2010 поверх SSMS для разработки баз данных?

Visual Studio 2010 представляет проекты баз данных и целый ряд связанных функций, которые предположительно облегчают разработку баз данных. Я много лет использовал SQL Server Management Studio (SSMS), чтобы без проблем разрабатывать свои базы данных.

• Зачем мне беспокоиться о VS2010, когда у меня работает SSMS? Что конкретно делает лучше, чем SSMS?
• Но, возможно, моя предпосылка неверна, и SSMS все еще превосходит VS для разработки баз данных. Если да, то в чем конкретно это правда?

На самом деле, я был немного не в восторге от VS2010, если честно. Я думаю, что в старой школе создать сценарий таблицы и файлы для хранимых процедур легче работать. Если вам нужно управление схемами, вы можете получить Redgate SQL Compare Pro за несколько сотен долларов.

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

Хотя я предпочитаю SSMS, я использовал оба. Некоторые плюсы и минусы:

• SSMS имеет пользовательский интерфейс, который «просто работает» хорошо для разработки SQL. Простое создание и использование сценариев создания намного удобнее, чем обручи VS2010, которые заставляют вас прыгать. Гораздо более гибкий (+ SSMS).

• VS2010 имеет базовое управление схемами (т. Е. Генерация разностных / патч-скриптов) (+ VS2010). Однако это не так уж хорошо и имеет некоторые недостатки. Например, это соответствует ограничениям на имя. Если у вас есть проверка или ограничения по умолчанию для столбца без присвоения им имен, SQL Server генерирует случайное имя за кулисами. Это приведет в замешательство VS2010, если вы установите скрипт на другом компьютере, так как ограничения могут иметь разные имена. Redgate дешевле и лучше. (+ VS2010, но с недостатками).

• VS2010 действительно неуклюжий - вам нужно иметь один файл для каждой таблицы или другого объекта БД. По сути, вы должны делать то, что VS2010, что довольно громоздко. (- VS2010)

• VS2010 также несколько хрупкий и интеграция управления исходным кодом является ненадежным. Даже в простой базе данных каждая таблица, ограничение, хранимая процедура, индекс и другой объект базы данных являются своим собственным файлом. Файлы добавляются в проект постоянно, намного быстрее, чем типичный программный проект с (скажем) C #. С оптимистичным параллелизмом он имеет тенденцию молча отбрасывать файлы из проекта, когда проверки происходят из-за синхронизации. Даже при хорошей командной дисциплине отзывы от интерфейса о статусе очень плохие. Это будет катастрофа на сложной модели. (-VS2010 - я бы почти посчитал это недостатком для большого проекта).

• SSMS поставляется с SQL Server - не может побить цену (+ SSMS).

• VS2010 до сих пор не имеет надлежащего хранилища, такого как, скажем, PowerDesigner или Oracle Designer. Вы не можете легко запросить модель данных, не установив ее в базу данных. (- VS2010).

В целом, я бы оценил VS2010 около B-. Он был неуклюжим в относительно простом проекте базы данных с двумя таблицами фактов и примерно 15 измерениями.

Самая большая модель данных, которую я когда-либо делал, была для системы управления делами в суде, которая имела около 560 таблиц. Я не рекомендовал бы VS2010 для проекта такого размера (я сделал это на Oracle Designer). По сути, он пытается быть умным, и парадигма не очень хорошо работает. Вам лучше использовать лучший в своем роде инструмент моделирования, такой как PowerDesigner, или просто использовать сценарии создания таблиц вручную.

SSMS простая и надежная, но ручная. У вас есть практически неограниченный контроль над тем, как вы хотите управлять моделью. Объедините его с менеджером схемы, таким как Redgate SQL Compare, и, возможно, с хорошим инструментом моделирования, таким как PowerDesigner, и вы получите гораздо лучший пакет, чем VS2010.

Резюме Я не уверен, что мог бы процитировать какие-либо убийственные функции или преимущества, кроме (возможно) интеграции с решениями VS, содержащими другие проекты. Если у вас уже есть VS2010 Premium или Ultimate, то вы получите несколько некорректный инструмент для разработки баз данных, добавленный в вашу цепочку инструментов .Net. Он интегрирует проекты БД в ваше решение VS, так что вы можете использовать его, по крайней мере, для создания сценариев развертывания sproc.

Тем не менее, VS не имеет инструмента моделирования, о котором можно говорить, поэтому PowerDesigner или даже Erwin лучше в этом смысле. Управление схемами Redgate намного лучше, а SQL Compare Pro довольно дешев (около 400 фунтов стерлингов IIRC). IMHO SSMS работает намного лучше для разработки T-SQL, но вы, безусловно, можете сделать это с VS2010.

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

Альтернатива

Я полагаю, что не стоит слишком много грызть VS2010, не предлагая хотя бы одну альтернативу и не выделяя ее плюсы и минусы. Для этого я возьму большой проект. Хотя я в основном занимаюсь A / P в эти дни, я был вовлечен в проект на 100+ человеко-лет, где я делал модель данных (и некоторую работу по разработке) и пару других в диапазоне 10 человеко-лет, где я в основном работал в качестве аналитика или разработчика. В основном я сейчас работаю над системами хранилищ данных, но крупные проекты были в основном приложениями. Основываясь на моем опыте работы с различными инструментами, вот несколько предложений по альтернативной цепочке инструментов:

• VS2010 профессиональный или выше. Вы можете или не можете использовать функции управления проектами премиум или премиум.
• Subversion, AnkhSVN и TortoiseSVN - лучше, чем TFS в любой день, и прекрасно играет с VS. Это также вполне подойдет для использования в локальных хранилищах для параллельных рабочих процессов разработки.
• SSMS для разработки T-SQL - Управление проектами и интеграция SC не очень хороши, но хорошо работают для разработки баз данных.
• Проект БД VS2010 для отслеживания sproc-файлов - немного неуклюжий, если вы используете SSMS, но работает нормально. Он также будет генерировать сценарии развертывания.
• PowerDesigner - намного лучше при моделировании базы данных и управлении элементами схемы БД. Это также делает UML, если вы хотите вникнуть в MDA. Если вы хотите руководствоваться своим дизайном БД из объектной модели, вы можете вместо этого рассмотреть Sparx EA. Он лучше всех работает с Meta CASE (расширяемой метамоделью) из всех инструментов CASE, которые я видел, хотя его моделирование базы данных оставляет желать лучшего.
• SQL Compare pro - используйте это для генерации сценариев исправления БД или для проверки сценариев ручного исправления (см. 1 ниже).
• Framemaker - Гораздо более стабильные и лучшие возможности для групповой работы, чем Word, если у вас есть несколько аналитиков, работающих над спецификацией. Он также поддерживает условное включение, так что вы можете иметь версии версий спецификации со скрытыми изменениями WIP. MIF и MML позволяют довольно легко интегрировать документы API и словари данных в спецификации документов. Это весьма полезно, так как вы можете сделать перекрестную ссылку на них в спецификации. Привязки текстовых меток делают перекрестные ссылки стабильными при повторном импорте. Вы также можете использовать TCS для получения документов из одного источника в формате PDF, HTML и CHM.
• Средство отслеживания проблем с открытым исходным кодом - много хороших программ с открытым исходным кодом (например, TRAC, Bugzilla, чтобы назвать пару, которую я использовал). С открытым исходным кодом легче изменить или интегрировать в пользовательский рабочий процесс, и вы не можете превзойти цену.
• NUnit или другие инструменты тестирования - любые инструменты автоматического тестирования, наиболее соответствующие вашим требованиям.
• Все, кроме проекта MS - Считается вредным. Проект MS имеет очень внутреннюю направленность и вынуждает планы проекта в модель, которая не представляет эффективно неопределенность, риск или зависимость от заинтересованных сторон или других третьих сторон (см. 2 ниже).

Плюсы: Лучшее моделирование базы данных и управление схемами, чем VS2010, лучшая система контроля версий, более легкая настройка рабочего процесса сборки и проекта, лучшее управление спецификациями и документацией.

Минусы: Больше усилий по интеграции инструментов, ограниченная интеграция БД в процесс сборки.

Допущения: Предполагается, что управление процессом изменения / выпуска более важно, чем автоматическое или тесно интегрированное управление выпуском для схем БД. Также предполагается, что автоматизированное управление схемами БД не является надежным на 100%.

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

1. QA на патчи БД. В больших схемах может потребоваться ручная установка исправлений для действующих систем, особенно если исправления связаны с миграцией данных. Например, может быть желательно иметь сценарии отката и отката для поддержки возврата изменений в случае необходимости. В этом случае вам понадобится средство для проверки правильности работы патча. Если вы управляете схемой базы данных в репозитории, вы можете протестировать сценарии, настроив их перед базой данных и сгенерировав справочную базу данных из репозитория. Запуск сценария исправления в базе данных before должен синхронизировать его с моделью хранилища. Для проверки этого можно использовать инструмент сравнения схем.

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

Я занимался тем, как структурировать ответ на этот вопрос, так как это было первоначально отправлено. Это сложно, так как в случае VS2010 речь идет не об описании функций и преимуществ инструмента. Речь идет о том, чтобы убедить читателя сделать фундаментальный сдвиг в их подходе к разработке баз данных. Не просто.

На этот вопрос есть ответы от опытных специалистов по базам данных, с фоновым сочетанием, охватывающим DBA, developer / dba, а также OLTP и хранилище данных. Мне нецелесообразно подходить к этому для каждого аспекта разработки базы данных за один раз, поэтому я попытаюсь обосновать конкретный сценарий.

Если ваш проект соответствует этим критериям, я думаю, что для VS2010 есть веские аргументы:

• Ваша команда использует VS2010 для разработки приложений.
• Ваша команда использует TFS для контроля версий и управления сборкой.
• Ваша база данных - SQL Server.
• Ваша команда уже прошла или заинтересована в автоматическом тестировании VS.

Если вы оцениваете VS2010 для разработки баз данных, вашей библией будет Руководство по базам данных Visual Studio от Visual Studio ALM Rangers . Все последующие цитаты, на которые нет ссылок, будут взяты из этого документа.

Пошли тогда ...

Почему процесс разработки баз данных отличается от разработки приложений?

Данные. Если бы не эти неприятные данные, разработка баз данных была бы пустяком. Мы могли бы просто СОБРАТЬ все на каждом выпуске и забыть об этом хлопотном управлении изменениями.

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

Что не так с SSMS?

Это называется SQL Server Management Studio по причине. В качестве отдельного инструмента нецелесообразно управлять своими усилиями по разработке, если вы собираетесь следовать принятым передовым методам.

Только с помощью сценариев, чтобы осмысленно применять установленные методы контроля версий к вашей разработке, вам придется поддерживать как определения объектов (например, сценарий CREATE TABLE), так и сценарии изменения (например, ALTER TABLE) И усердно работать над тем, чтобы они оставались синхронизированными.

Цепочка версий для внесения изменений в таблицу довольно быстро сходит с ума. Очень упрощенный пример:

-- Version 1
CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20))

-- Version 2
CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20), Description VARCHAR(50))

-- Version 3
CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20), Description VARCHAR(100))

В версии 3 скрипт изменения базы данных содержит:

ALTER TABLE dbo.Widget ADD Description VARCHAR(50)
ALTER TABLE dbo.Widget ALTER COLUMN Description VARCHAR(100)

Если оперативная версия этой базы данных - версия 1, а наш следующий выпуск - версия 3, сценарий ниже будет всем необходимым, но вместо этого будут выполняться оба оператора ALTER.

ALTER TABLE dbo.Widget ADD Description VARCHAR(100)

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

Так что-нибудь не так с SSMS? Нет, это хорошо для того, для чего это хорошо, для администрирования и управления SQL Server. Чего он даже не притворяется, так это помощи разработчику базы данных в (иногда) очень сложной задаче управления изменениями.

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

А как насчет SSMS + <- вставить инструмент сравнения схем ->?

Это определенно шаг в правильном направлении и отнимает много ручного труда, необходимого для поддержки сценариев. Но (и это большое но), как правило, это ручные шаги.

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

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

Если вы и ваша команда одни из немногих, кто имеет полностью автоматизированное сравнение и развертывание схем, снимаю шляпу перед вами! Ребята, вы, скорее всего, будете открыты для преимуществ, которые VS2010 может предложить:

• Вы уже приняли, что ручные шаги опасны.
• Вы видите ценность автоматизации.
• Вы готовы потратить время, необходимое для его работы.

Если вы не можете создать сборку за один шаг или развернуть ее за один шаг, процесс разработки и развертывания нарушен. Если вы так не думаете, спросите Джоэла Спольски .

Почему VS2010?

Вопрос, который поставил @NickChammas, - поиск потрясающих функций, демонстрирующих, почему VS2010 меняет правила игры при разработке баз данных. Я не думаю, что смогу обосновать это основанием.

Возможно, комично, где другие видят недостатки в этом инструменте, я вижу веские причины для принятия:

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

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

Принятие проектов баз данных может потребовать умственного сдвига ( старые привычки трудно сломать ) для некоторых разработчиков или, по крайней мере, изменения в процессе или рабочих процессах. Разработчикам, которые разработали приложения базы данных, в которых производственная база данных представляет текущую версию базы данных, необходимо будет принять подход, основанный на исходном коде, когда исходный код становится средством, в которое вносятся изменения в базы данных . В проектах базы данных Visual Studio проект и исходный код являются «единой версией истины» для схемы базы данных и управляются с использованием рабочих процессов SCM, которые, вероятно, уже используются разработчиком или организацией для других частей их стека приложений. Для данных производственная база данных остается «Единой версией правды», как и должно быть.

Мы достигли фундаментального сдвига, необходимого для успешного внедрения подхода VS2010 к разработке баз данных ...

Рассматривайте свою базу данных как код

Больше не нужно менять живую базу данных. Каждое изменение базы данных будет следовать той же схеме, что и изменение приложения. Изменить источник, построить, развернуть. Это не временное изменение направления от Microsoft, это будущее для SQL Server . База данных как код здесь, чтобы остаться.

Разработчик базы данных определяет форму объекта для версии приложения, а не то, как преобразовать существующий объект в ядре базы данных в нужную форму. Вы можете спросить себя: как это развертывается в базе данных, которая уже содержит таблицу клиентов? Это где движок развертывания вступает в игру. Как упоминалось ранее, механизм развертывания возьмет скомпилированную версию вашей схемы и сравнит ее с целью развертывания базы данных. Разностный механизм создаст необходимые сценарии для обновления целевой схемы в соответствии с версией, которую вы развертываете из проекта.

Да, есть другие инструменты, которые следуют аналогичному шаблону, и для проектов, которые выходят за рамки ограничений, которые я наложил на свой ответ, они заслуживают равного рассмотрения. Но если вы работаете с Visual Studio и Team Foundation Server ALM, я не думаю, что они могут конкурировать.

Что не так с проектами баз данных VS2010?

• Они не идеальны . Но если вы знаете об ограничениях и проблемных областях, вы можете их обойти.
• Сложные перемещения данных по- прежнему требуют осторожности и внимания, но учитываются сценариями до / после развертывания.

Редактировать: Так в чем же тогда ваша точка зрения?

@AndrewBickerton упомянул в комментарии, что я не ответил на первоначальный вопрос, поэтому я постараюсь подвести итог: «Почему я должен использовать Visual Studio 2010 поверх SSMS для разработки своей базы данных?» Вот.

• SSMS не является инструментом разработки баз данных. Да, вы можете разрабатывать TSQL с SSMS, но он не предоставляет богатых возможностей IDE VS2010.
• VS2010 предоставляет платформу для обработки вашей базы данных как кода.
• VS2010 приносит статический анализ кода в код вашей базы данных.
• VS2010 предоставляет вам инструменты для полной автоматизации цикла сборки-развертывания-тестирования.
• SQL2012 и Visual Studio vNext расширяют возможности проектов баз данных. Познакомьтесь с VS2010 прямо сейчас, и вы получите преимущество по инструментам разработки баз данных следующего поколения.

VS может показаться отличным, если вы не знаете SSMS или использовали сторонние инструменты. Пробелы в VS выделяются, если вы используете инструменты Red Gate для сравнения схем и т. Д. И бесплатные плагины SSMS тоже.

Биты контроля исходного кода вводят в заблуждение: в производственной базе данных находится ваша справочная копия. Не то, что использует разработчик. Видеть

• https://stackoverflow.com/q/1597085/27535
• https://stackoverflow.com/q/4433153/27535

Я широко использую Visual Studio (ну, BIDS) для разработки отчетов SSRS и пакетов SSIS. Я не смог бы сделать что-то очень хорошо, если вообще, в Management Studio. Visual Studio представляет собой гораздо более полную и интегрированную среду разработки, и она намного лучше подключается к системам управления версиями. И это все отражается на цене!

Честно говоря, мой голос идет прямо в SQL Server Management Studio для проектирования, разработки и (очевидно) администрирования базы данных. Проще набрать:

create table newTable
(
    someId int identity(1, 1) not null primary key clustered,
    ...... you get the idea
)

Затем нажмите во всех нужных местах. SSMS - это отличная компоновка и абсолютно потрясающая работа. И я по натуре разработчик программного обеспечения .NET. Но когда дело доходит до проектирования и кодирования базы данных, я выберу SSMS 11 раз из 10.

Наилучшей практики не существует, но с помощью проекта базы данных VS 2010 и контроллера исходного кода (VSS 2010, Subversion и т. Д.) Вы можете создать версию своей базы данных.

Я рекомендую сначала спроектировать базу данных непосредственно в SSMS. После того, как ваша база данных почти готова, импортируйте ее в проект базы данных VS 2010. После завершения импорта вы всегда должны добавить новый скрипт в проект базы данных, чтобы отслеживать все изменения. Вы можете использовать функцию сравнения проекта базы данных, чтобы получить все изменения с сервера разработки и импортировать все эти сценарии непосредственно в ваш проект. Теперь вам просто нужно «зафиксировать» ваши изменения в контроллере исходного кода.

С помощью этого метода вы можете иметь версионную базу данных. Вы можете определить версию каждой модификации и откатить изменения.

Это не единственное преимущество. В этом типе проекта вы можете сравнить любые базы данных с вашим проектом, чтобы записать изменения, а с помощью командной строки SQL PowerShell вы можете обновить все свои базы данных с помощью того же сценария: этот сценарий является схемой XML вашей базы данных. Он будет выполнять только необходимые команды для обновления ваших баз данных. У вас также есть возможность сделать модульный тест в вашей базе данных. Другая хорошая статья для проекта базы данных доступна здесь . С помощью функции развертывания вы можете использовать pre-script и post-script. С помощью этих сценариев вы можете проходить проверку или вставлять данные в ваши системные таблицы.

Вот хорошая пошаговая процедура для базы данных проекта.

Я использую SSMS больше, чем VS2010, потому что он там, когда я устанавливаю SQL Server. Это, наверное, самое главное, почему SSMS используется больше, чем VS2010, имхо.

Я также обнаружил, что такие производители, как Red-Gate, выпускают инструменты, которые интегрируются с SSMS и не обязательно VS2010. Это может быть положительным в том смысле, что позволяет улучшить SSMS, чего нет у Microsoft. Одним из примеров этого является система управления исходным кодом SQL Red-Gate, которая является надстройкой к SSMS, которая позволяет подключать SSMS к системе управления исходным кодом вашей компании, будь то Visual Team Foundation или что-то еще. VS2010 имеет эту встроенную функцию, но по сравнению с ценой инструмента Reg-Gate я просто сэкономил кучу денег, не покупая VS2010.

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

Если вы начали играть с SQL Server 2012, вы могли заметить, что SSMS медленно, но верно набирает VS2010. Так что, в конце концов, вы не сможете различить их.