Чому я повинен використовувати Visual Studio 2010 над SSMS для розробки моєї бази даних?


42

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

  • Чому я повинен турбуватися з VS2010, коли SSMS працює на мене? Що, зокрема, робить це краще, ніж SSMS?
  • Але, можливо, моя помилка неправильна, і SSMS все ще козирує VS для розробки баз даних. Якщо так, то якими конкретними способами це правда?

2
З накопичених до цього часу відповідей, я підозрюю, що респонденти не використовують жоден інструмент бази даних VS2010 таким чином.
Марк Сторі-Сміт

2
@ MarkStorey-Smith - Так, і я наступного тижня буду розгортати всіх із своєю відповіддю. З того, що я дізнався і використовував до сих пір, VS 2010 є інструментом для розробки баз даних.
Нік Чаммас

Насправді у вас вже були проекти баз даних у попередніх версіях Visual Studio, але вони були доступні лише у преміум-виданнях, IIRC.
gonsalu

1
Попередні версії були дуже різними.
Марк Сторі-Сміт

Я використовую лише SSMS. SSMS цілком здатний робити те, що потрібно зробити. Нашим серверним матеріалам не потрібно знати, що там ...
Спрошено

Відповіді:


27

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

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

Хоча я віддаю перевагу 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 або навіть Ервін краще з цього приводу. Управління схемами Redgate набагато краще, а SQL Compare Pro - досить дешево (близько 400 доларів IIRC). IMHO SSMS працює набагато краще для розробки T-SQL, але ви, звичайно, можете це зробити з VS2010.

VS2010 premium не набагато дешевше, ніж найкращий інструмент моделювання баз даних, а VS2010 Ultimate - принаймні так само дорого. За рахунок тісної інтеграції зі своїм проектом VS, можливо, ви могли б зробити краще із сторонніми інструментами.

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

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

  • VS2010 професійний або вище. Ви можете або не хочете використовувати функції управління проектами преміум-класу.
  • Subversion, AnkhSVN і TortoiseSVN - Краще, ніж TFS в будь-який день і чудово грає з VS. Це також підходить для ведення місцевих сховищ для одночасних робочих напрямків розвитку.
  • SSMS для розробки T-SQL - Управління проектами та інтеграція в SC не дуже добре, але добре працює для розробки БД.
  • Проект DB VS2010 для відстеження проростових файлів - трохи незграбний, якщо ви використовуєте SSMS, але працює добре. Він також створить сценарії розгортання.
  • PowerDesigner - краще моделювати базу даних та керувати елементами схеми БД. Він також робить UML, якщо ви хочете сильно потрапити в MDA. Якщо ви хочете керувати дизайном БД з об'єктної моделі, замість цього ви можете розглянути Sparx EA. Це найкраща робота Meta CASE (розширювана мета-модель) будь-якого інструменту CASE, який я бачив, хоча моделювання його баз даних залишає бажати кращого.
  • SQL Compare pro - використовуйте це для створення сценаріїв патчів DB або для тестування сценаріїв патчу вручну (див. 1 нижче).
  • Framemaker - набагато стабільніші та кращі функції групового програмного забезпечення, ніж Word, якщо у вас є кілька аналітиків, які працюють над специфікацією. Він також підтримує умовне включення, тому ви можете мати версії випуску специфікації зі змінами WIP, прихованими. MIF та MML дозволяють досить легко інтегрувати документи та словники даних у специфікаційні документи. Це досить корисно, оскільки ви можете перехресно посилатися на них у специфікації. Текстові анкери для етикетки роблять перехресні посилання стабільними при повторному імпорті. Ви також можете використовувати TCS для одноразового виведення документа у форматі PDF, HTML та CHM.
  • Відстежувач проблем з відкритим кодом - багато хороших з відкритим кодом (наприклад, TRAC, Bugzilla, щоб назвати пару, яку я використав). З відкритим кодом їх простіше змінювати або інтегрувати в спеціальний робочий процес, і ви не можете перемогти ціну.
  • NUnit або інші інструменти тестування - будь-який автоматизований інструмент тестування найбільш відповідає вашим вимогам.
  • Все, крім проекту MS - вважається шкідливим. Проект МС дуже дивиться всередину і змушує плани проектувати модель, яка фактично не представляє невизначеності, ризику чи залежності від зацікавлених сторін чи інших третіх сторін (див. 2 ​​нижче).

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

Мінуси: Більше зусиль для інтеграції інструментів, обмежена інтеграція БД у процес збирання.

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

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

  1. QA на патчі БД. На великій схемі ви можете мати процедуру вручну виправлення для живих систем, особливо якщо патчі передбачають міграцію даних. Наприклад, може бути бажаним мати сценарії відката та відкоту, щоб підтримувати резервне зміна, якщо це необхідно. У цьому випадку ви хочете мати можливість перевірити, чи дійсно патч працює належним чином. Якщо ви керуєте схемою бази даних у сховищі, ви можете протестувати сценарії, встановивши перед базами даних і генеруючи репозиторій бази даних. Запуск сценарію патча на базі даних раніше повинен синхронізувати його з моделлю репозиторію. Для перевірки цього інструменту можна використовувати інструмент порівняння схем.

  2. Останнім часом я робив набагато більше роботи зі зберіганням даних та інтеграцією, ніж передбачу розробку додатків, тому я стикаюся з цим частіше, ніж у більшості випадків працює команда розробників. Однак інструменти та методики управління проектами виконують дуже погану роботу з управління зовнішніми зацікавленими сторонами. У проекті інтеграції, такому як сховище даних, я дуже хочу побачити інструмент управління проектами, який дійсно штовхає зовнішні залежності (тобто ті, якими я не керую) перед управлінням програми. У будь-якому нетривіальному інтеграційному проекті зовнішні залежності є на сьогодні найбільшими рушіями витраченого часу.


Дякую за оновлення вашої відповіді з усією цією деталлю. Це набагато цінніше зараз.
Nick Chammas

2
Не згоден один файл на громіздкий об’єкт. Це не спосіб VS2010, це управління джерелом 101. Ви не визначаєте кілька класів C # в одному файлі, чи не так?
Марк Сторі-Сміт

2
Чесно кажучи, я не стежу за цим. По-перше, інструменти керують цими файлами для вас, це не додає накладних витрат до моєї продуктивності. По-друге, таблиці, ключі, індекси та обмеження відокремлюються через те, що: а) це окремі об'єкти, логічно та фізично;
Марк Сторі-Сміт

1
Підмітальні висловлювання на кшталт "інструменти для управління файлами для вас" не дуже корисні, тому що моє зауваження полягає в тому, що явно їх немає - принаймні не надійно. VS2010 може працювати нормально для одного користувача; це не дуже добре працювало для команди. Мій досвід полягає в тому, що у партнера по золоту MS виникли проблеми з керуванням простим звітом з даними бухгалтерського обліку. Це були не люди.
Занепокоєння

2
@ConcernedOfTunbridgeWells не розглядайте будь-які мої коментарі як антагоністичні чи аргументативні, це не мій намір. Мені дуже цікаво почути, чому VS2010 не застосовується більш широко, тому що я часто створюю завдання, щоб команди вивчали його. Якщо ви можете витратити час на обговорення більш детально , мені буде цікаво почути ваші думки.
Марк Сторі-Сміт

19

Я розмовляв із тим, як структурувати відповідь на це питання, оскільки він був опублікований спочатку. Це складно, оскільки справа у VS2010 не стосується опису функцій та переваг цього інструменту. Йдеться про переконання читача зробити принциповий зрух у своєму підході до розробки баз даних. Нелегко.

На це питання є відповіді досвідчених професіоналів баз даних, у яких довідковий мікс охоплює DBA, розробник / 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 сервером. Те, що він навіть не претендує на те, це допомогти розробнику бази даних з (часом) дуже складною задачею управління змінами.


Якщо ви не можете створити кожну версію бази даних від джерела та оновити її до будь-якої майбутньої версії, ваш джерело контролю порушено. Якщо ви так не думаєте, запитайте Еріка Сінка .


Що щодо SSMS + <- вставити інструмент порівняння схеми ->?

Це, безумовно, крок у правильному напрямку та забирає значну частину ручних зусиль, необхідних для підтримки сценаріїв. Але (і це велике, але), як правило, є ручні кроки.

Популярні засоби порівняння схем можуть бути повністю автоматизовані та інтегровані в процес збирання. Однак, на моєму досвіді, більш поширеною практикою є порівняння, яке проводиться вручну, отримані сценарії підкреслюються, перевіряються в керування джерелом, а потім виконуються вручну для розгортання. Не добре.

У будь-який момент, коли ми маємо помилкових людей, потрібно втягуватися в процес збирання або розгортання, ми вводимо ризик і робимо процес не повторюваним.

Якщо ви та ваша команда є одними з небагатьох, які мають повністю автоматизоване порівняння схем та розгортання, шапки вам! Ви, хлопці, найімовірніше, можете відкрити переваги, які може запропонувати VS2010 як:

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

Якщо ви не можете створити збірку за один крок або розгорнути в один крок, процес розробки та розгортання порушений. Якщо ви так не думаєте, запитайте Джоела Спольського .


Чому VS2010?

Поставлене запитання @NickChammas шукає вбивць, які демонструють, чому VS2010 - це зміна ігор для розробки баз даних. Я не думаю, що я можу скласти справу на цій основі.

Можливо, комічно, коли інші бачать недоліки в цьому інструменті, я бачу вагомі причини прийняття:

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

Якщо ви є єдиним DBA проекту, керуючи всіма змінами в базі даних, ці міркування повинні здаватися смішними, що межують з абсурдними. Якщо ви думаєте, що у @BrentOzar є пункт, і одне з нових правил - це те, що всі є DBA , вам потрібно буде контролювати зміну бази даних таким чином, з яким може працювати кожен розробник у команді.

Прийняття проектів баз даних може вимагати зрушення психічного розвитку ( старі звички важко порушити ) для деяких розробників або принаймні змінити процес чи робочі процеси. Розробникам, які розробили додатки для баз даних, де виробнича база даних представляє поточну версію бази даних, потрібно буде прийняти підхід, заснований на вихідному коді, коли вихідний код стає засобом, до якого вносяться зміни в бази даних . У проектах баз даних 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 зараз, і ви ознайомилися з інструментами розробки баз даних нового покоління.

Ніби корисна відповідь з деякими застереженнями: 1) Ви пропустили критерій "Ви розробляєте автономні програми, що надсилаються на клієнтські сайти (тобто: в дикій природі існує декілька копій однієї бази даних, а нові [порожні] створюються") / продається весь час) "2) Ви відповіли, чому ми повинні ставитися до бази даних як до коду та керувати циклами розвитку, побудови, розгортання (з чим я вже згоден). Я не бачу переконливої ​​причини у вашій відповіді, чому ми повинні використовувати VS2010 як механізм для досягнення цього. +2 (продумана відповідь) & -1 (не відповідає на фактичне запитання)
Ендрю Бікертон

2
Який "багатий IDE" вам потрібен для сценарію SQL?
gbn

1
Переваги автоматизованих циклів побудови-розгортання-випробування видно нижче. Автоматизовану частину прямого розгортання я обмежував би «від руки», тобто не вимагав ніяких ручних кроків.
Марк Сторі-Сміт

1
Крім цього, ваші аргументи щодо інтеграції мають певні заслуги. Наскільки добре це працює в загальному випадку? У мене були проблеми з цим, але смію сказати, що це може спрацювати.
ЗанепокоєнийOfTunbridgeWells

2
@Nick Я зроблю це для вас :-)
Джек Дуглас

7

VS може здатися чудовим, якщо ви не знаєте SSMS або не використовували сторонні інструменти. Прогалини в VS виділяються, якщо ви використовуєте інструменти Red Gate для порівняння схем тощо. І безкоштовні модулі SSMS теж.

Біти управління джерелами вводять в оману: те, що є у виробничій базі даних, - це ваша довідкова копія. Не те, що використовує розробник. Побачити


1
Я повинен був би погодитися з цим - Ви можете зробити дизайн / розробку та управління схемами БД за допомогою VS2010, але є сторонні ланцюги інструментів, які роблять це так, набагато краще.
Занепокоєння

1
Чому б ви взяли виробництво як свою довідкову копію? Я думаю, що це погана практика, і, мабуть, також є ознакою того, що ваш контроль над джерелом порушений. Чому ваш код бази даних не повинен належати до життєвого циклу розвитку, як і все інше?
Нік Чаммас

@ NickChammas: Я маю на увазі відновлену копію виробництва. У моєму поточному магазині те, що знаходиться в контролі джерела, не відповідає реальній БД. У моєму останньому, схоже на інші команди. Те, що розгорнуто за допомогою сценарію зміни, - це не те, над чим розробники працюють ...
gbn

6

Я широко використовую Visual Studio (ну BIDS) для розробки звітів про SSRS та пакетів SSIS. Я не міг зробити ні дуже добре, якщо взагалі, в студії менеджменту. Visual Studio - це набагато повніше та інтегрованіше середовище розробки, і воно також підключається до систем контролю джерел набагато краще. І це все відбивається на ціні!


6

Якщо чесно, моє голосування направляється безпосередньо на студію управління SQL Server для розробки баз даних, розробки та (очевидно) адміністрування. Просто набрати:

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

Потім натисніть у всіх потрібних місцях. SSMS - це чудовий макет і абсолютно вибух для роботи. І я за своєю природою розробник програмного забезпечення .NET. Але коли справа стосується дизайну та кодування бази даних, я виберу SSMS 11 разів із 10.


У Visual Studio ви вводите таблицю DDL точно так само. Ви думаєте про щось інше?
Нік Чаммас

1
@Nick Я, мабуть, сформулював це неправильно. Я знаю, що ви можете це зробити в VS, але моє, що приємно мати спеціальний інструмент для цієї конкретної (і великої) задачі. Я, безумовно, звір звички, і я створив SSMS свою звичку. :)
Thomas Stringer

2
Дійсно? Можливості рішення / проекту SSMS вважають, що їх додав стажист за 2 тижні до запуску.
Марк Сторі-Сміт

1
@ MarkStorey-Smith - це питання про те, як SSMS насправді не підтримує проект / рішення, і що важливо для того, щоб команди могли добре працювати в IDE по всій раді?
jcolebrand

3
Одним з лайнерів буде те, що SSMS є інструментом адміністрування баз даних, VS2010 - це інструмент розробки бази даних.
Марк Сторі-Сміт

5

Не існує найкращої практики, але за допомогою проекту баз даних VS 2010 та контролера вихідного коду (VSS 2010, Subversion тощо) ви можете оновити свою базу даних.

Я рекомендую спершу розробити базу даних безпосередньо в SSMS. Після того, як ваша база даних буде майже готова, імпортуйте її у проект бази даних VS 2010. Після завершення імпорту ви завжди повинні додавати новий сценарій у проект своєї бази даних, щоб відслідковувати всі модифікації. Ви можете використовувати функцію порівняння проекту баз даних, щоб отримати всі зміни з сервера розробки та імпортувати всі ці сценарії безпосередньо у ваш проект. Тепер ви просто повинні "здійснити" свої зміни в контролері вихідного коду.

За допомогою цього методу ви можете мати базу даних, що переглядаються. Ви можете помітити версію кожної модифікації та повернути свої зміни.

Це не єдина перевага. З таким проектом ви можете порівняти будь-які бази даних з вашим проектом, щоб змінити сценарій, і за допомогою командного рядка SQL PowerShell ви можете оновити всі ваші бази даних тим самим сценарієм: цей сценарій є схемою XML вашої бази даних. Він буде виконувати лише необхідні команди для оновлення ваших баз даних. У вас також є можливість зробити тестовий блок у вашій базі даних. Інша хороша стаття для проекту бази даних доступна тут . За допомогою функції розгортання ви можете мати попередній сценарій та пост-скрипт. За допомогою цих скриптів ви можете мати перевірку, а також вставляти дані в свої системні таблиці.

Ось хороша покрокова процедура проекту баз даних.


4
Це не так, як слід робити розробку баз даних у VS2010, ви, здається, дещо пропустили точку. 1) Чому з однієї землі ви створили базу даних greenfield у SSMS та імпортували до VS? 2) Для відстеження змін вам не потрібно "завжди додавати новий сценарій у проект своєї бази даних". 3) Сценарії не є "xml-схемою" вашої бази даних.
Марк Сторі-Сміт

Ви коли-небудь пробували проект бази даних? 1 - Тому що ви можете імпортувати свою базу даних лише один раз, якщо ви не хочете сценарію, всі робіть максимум, що ви можете в SSMS для першого проекту бази даних. 2- Ви маєте рацію, що ви можете відстежувати зміни за допомогою інструмента порівняння VS2010, і VS2010 генерує їх для вас. 3- Спробуйте проект бази даних, коли ви розгорнете проект своєї бази даних, ви отримаєте XML-схему вашої бази даних для оновлення виробничих баз даних.
Ніко

2
Так, з ранніх і болючіших версій . Ви дійсно імпортуєте один раз, але ви синхронізуєте багато (не те, що вам колись доведеться робити це, якщо тільки ви не продовжуєте працювати поза середовищем). Більш точний опис того, що ви посилаєтесь на сценарій "XML Schema", полягає в тому, що інструменти підтримують мета-модель бази даних на основі XML, яку інструмент розгортання командного рядка використовує для створення команд, необхідних для оновлення цільової бази даних .
Марк Сторі-Сміт

2

Я більше використовую SSMS, ніж VS2010, тому що він є там, коли я встановлюю SQL Server. Це, мабуть, найважливіше, чому SSMS використовується більше, ніж VS2010, IMHO.

Я також виявив, що такі постачальники, як Red-Gate, викладають інструменти, що інтегруються з SSMS, а не обов'язково VS2010. Це може бути позитивним тим, що воно дозволяє покращити SSMS там, де Microsoft цього не зробила. Одним із прикладів цього є управління SQL Source Red-Gate, що є доповненням до SSMS, що дозволяє підключати SSMS до системи управління джерелами компанії, будь то Visual Team Foundation або що у вас є. У VS2010 є цей вбудований, але порівняно з ціною інструменту Reg-Gate я просто заощадив купу грошей, не купуючи VS2010.

Я думаю, що загалом це зводиться до переваг, ви працюєте з тим, що вам зручно. Якщо ви навчаєте нову людину і ви навчаєте їх на VS2010, то це стане їх перевагою, оскільки вони знають, як з цим подолатись.

Якщо ви почали грати з SQL Server 2012, можливо, ви помітили, що SSMS поступово, але впевнено набирає макіяж VS2010. Тож зрештою ви не зможете сказати різницю між ними.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.