데이터베이스 개발에 SSMS를 통해 Visual Studio 2010을 사용해야하는 이유는 무엇입니까?


42

Visual Studio 2010에는 데이터베이스 프로젝트 와 데이터베이스 개발을 용이하게하는 모든 관련 기능이 도입되었습니다 . 수년간 SQL Server Management Studio (SSMS)를 사용해 문제없이 데이터베이스를 개발했습니다.

  • SSMS가 작동 할 때 VS2010을 왜 귀찮게해야합니까? 특히 SSMS보다 더 나은 기능은 무엇입니까?
  • 그러나 아마도 내 전제는 정확하지 않으며 SSMS는 여전히 데이터베이스 개발 측면에서 VS를 능가합니다. 그렇다면 어떤 구체적인 방법으로 사실입니까?

2
지금까지 축적 된 답변으로부터 응답자가 의도 한 방식으로 VS2010 데이터베이스 도구를 사용 하지 않는 것 같습니다.
Mark Storey-Smith

2
@ MarkStorey-Smith-그래, 나는 다음 주 내 대답으로 모든 사람들을 흔들 것입니다. 내가 배운 지금까지 사용했던 바로는, VS 2010는 데이터베이스 개발을위한 도구입니다.
Nick Chammas

실제로 이전 Visual Studio 버전의 데이터베이스 프로젝트가 이미 있지만 Premium 버전 인 IIRC에서만 사용할 수있었습니다.
gonsalu

1
이전 버전은 매우 달랐습니다.
Mark Storey-Smith

SSMS 만 사용합니다. SSMS는 수행해야 할 작업을 완벽하게 수행 할 수 있습니다. 우리 서버 서버에는 무엇이 있는지 알 필요가 없습니다.
Asken

답변:


27

사실 저는 VS2010에 정직한 태도를 보였습니다. 구식 create table 스크립트와 저장 프로 시저에 대한 파일을 사용하는 것이 더 쉽다고 생각합니다. 스키마 관리가 필요한 경우 Redgate SQL Compare Pro를 몇 백 달러에 구입할 수 있습니다.

데이터베이스 모델링 도구가 정말로 필요한 경우 Powerdesigner 또는 심지어 Erwin은 특히 저렴하지는 않지만 훨씬 나은 작업을 수행합니다.

SSMS를 선호하지만 둘 다 사용했습니다. 몇 가지 장단점 :

  • SSMS에는 SQL 개발에 '잘 작동하는'사용자 인터페이스가 있습니다. VS2010이 당신을 뛰어 넘는 것보다 창조 스크립트를 만들고 사용하는 것이 훨씬 편리합니다. 훨씬 더 유연합니다 (+ SSMS).

  • VS2010에는 기본 스키마 관리 (예 : 차이 / 패치 스크립트 생성) (+ VS2010)가 있습니다. 그러나 그것이 전부는 아니며 결함이 있습니다. 예를 들어 이름의 제약 조건과 일치합니다. 이름을 지정하지 않고 열에 대한 검사 또는 기본 제약 조건이있는 경우 SQL Server는 장면 뒤에서 임의의 이름을 생성합니다. 제약 조건의 이름이 다를 수 있으므로 스크립트를 다른 컴퓨터에 설치하면 VS2010이 혼동됩니다. Redgate가 더 저렴하고 좋습니다. (+ VS2010이지만 결함이 있음).

  • VS2010은 정말 어색합니다. 각 테이블 또는 다른 DB 개체마다 하나의 파일이 필요합니다. 본질적으로 VS2010 방식을 수행해야합니다. 매우 번거 롭습니다. (-VS2010)

  • VS2010 또한 다소 취약하며 소스 제어 통합에 결함이 있습니다. 간단한 데이터베이스에서도 모든 테이블, 제약 조건, 저장 프로 시저, 인덱스 및 기타 데이터베이스 개체는 자체 파일입니다. 파일은 프로젝트에 항상 추가되며 C #을 사용하는 일반적인 프로그래밍 프로젝트보다 훨씬 빠릅니다. 낙관적 동시성으로 체크인이 동기화되지 않을 때 프로젝트에서 파일을 자동으로 삭제하는 경향이 있습니다. 좋은 팀 훈련을 받았더라도 상태에 대한 UI의 피드백은 매우 좋지 않습니다. 이것은 복잡한 모델에서 재앙이 될 것입니다. (-VS2010-큰 프로젝트의 경우 중단 점이라고 생각합니다.)

  • SSMS는 SQL Server와 함께 제공되며 가격을 능가 할 수 없습니다 (+ SSMS).

  • VS2010에는 여전히 PowerDesigner 또는 Oracle Designer와 같은 적절한 저장소가 없습니다. 데이터베이스에 데이터 모델을 설치하지 않고는 데이터 모델을 쉽게 쿼리 할 수 ​​없습니다. (-VS2010).

전반적으로, 나는 VS2010에 대해 B-를 평가 할 것입니다. 두 개의 팩트 테이블과 약 15 개의 차원이있는 비교적 간단한 데이터베이스 프로젝트에서는 서투른 것입니다.

내가 한 가장 큰 데이터 모델은 약 560 개의 테이블이있는 법원 사건 관리 시스템이었습니다. VS2010 프로젝트의 경우 VS2010을 권장하지 않습니다 (Oracle Designer에서 수행했습니다). 본질적으로 그것은 영리하려고 노력하고 패러다임은 실제로 그렇게 잘 작동하지 않습니다. PowerDesigner와 같은 동종 최고의 모델링 도구를 사용하거나 직접 테이블 스크립트 작성을 사용하는 것이 좋습니다.

SSMS는 간단하고 신뢰할 수 있지만 수동입니다. 모델 관리 방법을 거의 무한대로 제어 할 수 있습니다. Redgate SQL Compare와 같은 스키마 관리자 및 PowerDesigner와 같은 괜찮은 모델링 도구와 결합하면 VS2010보다 훨씬 더 나은 패키지가 있습니다.

요약 다른 프로젝트를 포함하는 VS 솔루션과의 통합 (아마도)과는 별도로 킬러 기능이나 이점을 인용 할 수 있는지 잘 모르겠습니다. 이미 VS2010 프리미엄 또는 Ultimate를 보유하고 있다면 .Net 툴 체인에 다소 결함이있는 데이터베이스 개발 툴이 제공됩니다. DB 프로젝트를 VS 솔루션에 통합하므로 적어도 sproc 배포 스크립트를 만드는 데 사용할 수 있습니다.

그러나 VS는 말할 모델링 도구가 없으므로 PowerDesigner 또는 심지어 Erwin이 그보다 더 좋습니다. Redgate의 스키마 관리가 훨씬 우수하고 SQL Compare Pro는 상당히 저렴합니다 (약 £ 400 IIRC). IMHO SSMS는 T-SQL 개발에 훨씬 효과적이지만 VS2010을 사용하면 확실히 할 수 있습니다.

VS2010 프리미엄은 동급 최고의 데이터베이스 모델링 도구보다 저렴하지 않으며 VS2010 Ultimate는 최소한 비싸다. VS 프로젝트와의 긴밀한 통합 비용으로 타사 도구를 사용하면 더 나은 작업을 수행 할 수 있습니다.

대안

적어도 하나의 대안을 제안하고 장단점을 요약하지 않고 VS2010을 너무 많이 깎아서는 안된다고 생각합니다. 이를 위해 큰 프로젝트를 가정하겠습니다. 나는 요즘 A / P 업무를 주로하고 있지만 데이터 모델 (및 일부 개발 작업)을 수행 한 100 명 이상의 직원 연도 프로젝트와 10 명의 직원 연도 범위 내에서 2 명이 근무했습니다. 분석가 또는 개발자로. 요즘에는 주로 데이터웨어 하우스 시스템에서 작업하지만 더 큰 프로젝트는 주로 응용 프로그램이었습니다. 다양한 툴에 대한 경험을 바탕으로 대체 툴 체인에 대한 제안 사항이 있습니다.

  • VS2010 전문가 이상. 프리미엄 또는 궁극의 프로젝트 관리 기능을 사용하거나 사용하지 않을 수 있습니다.
  • Subversion, AnkhSVN 및 TortoiseSVN-매일 TFS보다 우수하며 VS와 잘 어울립니다. 또한 동시 개발 워크 스트림을 위해 로컬 리포지토리를 농사로 만들 수도 있습니다.
  • T-SQL 개발을위한 SSMS-프로젝트 관리 및 SC 통합은 그다지 좋지 않지만 DB 개발 작업에는 적합합니다.
  • sproc 파일 추적을위한 VS2010 DB 프로젝트-SSMS를 사용하고 있지만 정상적으로 작동하는 경우 약간 어색합니다. 또한 배포 스크립트를 생성합니다.
  • PowerDesigner-데이터베이스 모델링 및 DB 스키마 항목 관리가 훨씬 우수합니다. MDA에 집중하고 싶다면 UML도 수행합니다. 객체 모델에서 DB 디자인을 추진하려면 Sparx EA를 대신 고려하십시오. 데이터베이스 모델링을 통해 원하는 것을 남길 수는 있지만 본 CASE 도구 중 Meta CASE (확장 가능한 메타 모델)가 가장 효과적입니다.
  • SQL Compare pro-DB 패치 스크립트를 생성하거나 수동 패치 스크립트를 테스트 할 때 사용합니다 (아래 1 참조).
  • 프레임 메이커-스펙에 대해 여러 분석가가있는 경우 Word보다 훨씬 안정적이고 더 나은 그룹웨어 기능입니다. 또한 조건부 포함을 지원하므로 WIP 변경 사항을 숨기고 버전의 사양 릴리스를 사용할 수 있습니다. MIF 및 MML을 사용하면 API 문서 및 데이터 사전을 사양 문서에 쉽게 통합 할 수 있습니다. 스펙에서 상호 참조 할 수 있으므로이 작업을 수행하는 것이 매우 유용합니다. 텍스트 레이블 앵커는 다시 가져올 때 상호 참조를 안정적으로 만듭니다. TCS를 사용하여 문서를 PDF, HTML 및 CHM 출력으로 단일 소싱 할 수도 있습니다.
  • 오픈 소스 이슈 트래커-좋은 오픈 소스 것들 (예 : TRAC, 내가 사용한 커플의 이름을 나타내는 Bugzilla). 오픈 소스 소스는 사용자 지정 워크 플로를 수정하거나 통합하기가 쉽고 가격을 능가 할 수 없습니다.
  • NUnit 또는 기타 테스트 도구-요구 사항에 가장 적합한 자동 테스트 도구
  • MS 프로젝트 이외의 것은 유해한 것으로 간주됩니다. MS 프로젝트는 매우 내부적으로보고 있으며 프로젝트 계획을 이해 관계자 또는 기타 제 3 자에 대한 불확실성, 위험 또는 종속성을 효과적으로 나타내지 않는 모델로 만듭니다 (아래 2 참조).

장점 : VS2010보다 향상된 데이터베이스 모델링 및 스키마 관리, 더 나은 버전 제어 시스템, 빌드 및 프로젝트 작업 흐름을 쉽게 사용자 지정하고 사양 및 문서를보다 효율적으로 관리 할 수 ​​있습니다.

단점 : 도구, 통합 된 DB 통합을 빌드 프로세스에 통합하려는 추가 노력.

가정 : DB 스키마에 대한 자동화 또는 긴밀하게 통합 된 릴리스 관리보다 변경 / 릴리스 프로세스 제어가 더 중요하다고 가정 합니다. 또한 자동화 된 DB 스키마 관리가 100 % 신뢰할 수 없다고 가정합니다.

굉장히 첨단 기술이나 매끄러운 통합은 아니지만 복잡한 프로젝트의 경우 귀여운 자동화 기능보다 제어에 더 관심이있을 것입니다. 나는 당신이 최고의 품종 도구 세트와 도구를 통합하는 데 필요한 모든 양조 도구와 테스트 스크립팅으로 더 나을 것이라고 주장합니다. 빌드를 (a) 비교적 이해하기 쉽고 (b) 완전히 자동화 된 상태로 유지하십시오.

  1. DB 패치에 대한 QA. 대규모 스키마에서는 특히 패치에 데이터 마이그레이션이 포함 된 경우 라이브 시스템에 대한 수동 패치 프로세스를 원할 수 있습니다. 예를 들어, 필요한 경우 변경 사항을 제거 할 수 있도록 롤 포워드 및 롤백 스크립트를 갖는 것이 바람직 할 수 있습니다. 이 경우 패치가 실제로 제대로 작동하는지 테스트 할 수있는 기능이 필요합니다. 저장소에서 데이터베이스 스키마를 관리하는 경우 데이터베이스 이전에 설정하고 저장소에서 참조 데이터베이스를 생성하여 스크립트를 테스트 할 수 있습니다. 이전 데이터베이스에서 패치 스크립트를 실행하면 리포지토리 모델과 동기화해야합니다. 이를 비교하기 위해 스키마 비교 도구를 사용할 수 있습니다.

  2. 최근 맞춤식 애플리케이션 개발보다 훨씬 더 많은 데이터웨어 하우스 및 통합 작업을 수행 했으므로 대부분의 경우 개발 팀보다 더 자주 발생합니다. 그러나 프로젝트 관리 도구 및 방법론은 외부 이해 관계자를 관리하는 일이 매우 열악합니다. 데이터웨어 하우스와 같은 통합 프로젝트에서 저는 프로그램 관리에 직면 할 때 외부 종속성 (예 : 내가 제어하지 않는 것)을 실제로 밀어내는 프로젝트 관리 도구를보고 싶습니다. 사소한 통합 프로젝트에서 외부 종속성은 시간 낭비의 가장 큰 원인입니다.


이 모든 세부 사항으로 답변을 업데이트 해 주셔서 감사합니다. 지금은 훨씬 더 가치가 있습니다.
Nick Chammas

2
번거롭고 객체 당 하나의 파일에 동의하지 않습니다. VS2010 방식이 아니며 소스 제어 101입니다. 단일 파일에 여러 C # 클래스를 정의하지 않습니까?
Mark Storey-Smith

2
솔직히, 나는 따르지 않습니다. 첫째, 도구가 이러한 파일을 관리하므로 생산성에 오버 헤드가 발생하지 않습니다. 둘째, 테이블, 키, 인덱스 및 제약 조건은 a) 논리적 및 물리적으로 분리 된 객체이므로 b) 데이터 이동과 관련된 리 팩터의 일부로 인덱스를 삭제 및 재생성하는 등 격리 된 상태에서 종종 조작합니다.
Mark Storey-Smith

1
'도구가 사용자를 위해 파일을 관리합니다'와 같은 진술은 도움이되지 않습니다. VS2010은 단일 사용자에게 정상 작동 할 수 있습니다. 팀에게는 잘 작동하지 않았습니다. 내 경험은 MS 골드 파트너가 간단한 회계 데이터 마트를 관리하는 데 문제가 있다는 것입니다. 사람들이 아니었다.
ConcernedOfTunbridgeWells

2
@ConcernedOfTunbridgeWells 제 의견은 어떤 식 으로든 적대적이거나 논쟁적인 것으로 보지 마십시오. VS2010이 왜 더 광범위하게 채택되지 않는지에 대해 매우 관심이 있습니다. 팀이 종종이를 조사하는 사례를 만들고 있기 때문입니다. 더 자세히 논의 할 시간을 아끼지 않는다면 , 여러분의 생각을 듣고 싶습니다.
Mark Storey-Smith

19

나는이 질문이 처음 게시 된 이후 로이 질문에 대한 답변을 구성하는 방법에 대해 이야기하고 있습니다. VS2010의 경우 도구의 기능과 이점을 설명하지 않기 때문에 어렵습니다. 이것은 독자가 데이터베이스 개발에 대한 접근 방식을 근본적으로 바꾸도록 설득하는 것입니다. 쉬운 일이 아닙니다.

DBA, 개발자 / dba 및 OLTP 및 데이터웨어 하우징에 걸친 배경 구성을 갖춘 노련한 데이터베이스 전문가의이 질문에 대한 답변이 있습니다. 데이터베이스 개발의 모든 측면에 대해 이것에 접근하는 것은 불가능합니다. 그래서 특정 시나리오에 대해 시도하고 사례를 만들 것입니다.

귀하의 프로젝트가 이러한 기준에 부합한다면 VS2010에 대한 매력적인 사례가 있다고 생각합니다.

  • 팀에서 응용 프로그램 개발에 VS2010을 사용하고 있습니다.
  • 팀에서 소스 제어 및 빌드 관리에 TFS를 사용하고 있습니다.
  • 데이터베이스가 SQL Server입니다.
  • 귀하의 팀은 이미 VS 자동 테스트를 받았거나 관심이 있습니다.

데이터베이스 개발을 위해 VS2010을 평가 하는 경우 Visual Studio ALM RangersVisual Studio Database Guide 가 성경이됩니다 . 참조가없는 따옴표는이 문서에서 나옵니다.

그럼 우리는 간다 ...

데이터베이스 개발 프로세스가 애플리케이션 개발과 다른 이유는 무엇입니까?

데이터. 그 성가신 데이터가 아니라면 데이터베이스 개발이 방해가 될 것입니다. 모든 릴리스에서 모든 것을 삭제하고 번거로운 변경 관리를 잊어 버릴 수 있습니다.

데이터베이스 테이블이나 다른 데이터 스키마의 모양에 영향을주는 응용 프로그램 개발 노력으로 변경 사항이 도입되면 데이터가 마이그레이션, 변환 또는 다시로드되기 때문에 데이터가 있으면 데이터베이스 변경 프로세스가 복잡해집니다. 이 변경 프로세스 전체에서 생산 품질 데이터와 운영 상태는 조직의 무결성, 가치 및 유용성을 위협 할 수있는 변경으로부터 보호되어야합니다.

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를 관리하고 관리하는 데 유용합니다. 심지어 척하지 않는 것은 데이터베이스 개발자가 (종종) 매우 복잡한 변경 관리 작업을 도와주는 것입니다.


소스에서 모든 버전의 데이터베이스를 빌드하고 향후 버전으로 업그레이드 할 수없는 경우 소스 제어가 손상된 것입니다. 그렇게 생각하지 않으면 Eric Sink에게 문의하십시오 .


SSMS + <-스키마 비교 도구 삽입->은 어떻습니까?

이것은 올바른 방향으로 나아가는 단계이며 스크립트를 유지 관리하는 데 필요한 많은 수동 노력을 제거합니다. 그러나 (그리고 큰 일이지만) 일반적으로 수동 단계가 필요합니다.

널리 사용되는 스키마 비교 도구는 완전히 자동화되어 빌드 프로세스에 통합 될 수 있습니다. 그러나 내 경험상 더 일반적인 관행은 비교를 수동으로 실행하고 결과 스크립트를 확인하고 소스 제어에 체크인 한 다음 수동으로 실행하여 배포하는 것입니다. 안좋다.

우리가 착오를 겪는 인간은 빌드 또는 배포 프로세스에 참여해야 할 때마다 위험을 초래하고 프로세스를 반복 할 수 없게 만듭니다.

귀하와 귀하의 팀이 완전히 자동화 된 스키마 비교 및 ​​배포 기능을 갖춘 소수의 팀에 속하면 여러분을 미워합니다! VS2010이 제공하는 이점에 대해 다음과 같이 공개 할 가능성이 가장 높습니다.

  • 수동 단계가 위험하다는 것을 이미 인정했습니다.
  • 자동화의 가치를 알 수 있습니다.
  • 당신은 그것이 작동하는데 필요한 시간을 기꺼이 투자 할 것입니다.

단일 단계에서 빌드를 만들거나 단일 단계에서 배포 할 수 없으면 개발 및 배포 프로세스가 중단 된 것입니다. 그렇게 생각하지 않는다면 Joel Spolsky에게 문의하십시오 .


왜 VS2010입니까?

@NickChammas가 제기 한 질문은 VS2010이 데이터베이스 개발을위한 게임 체인저 인 이유를 보여주는 킬러 기능을 찾고 있습니다. 나는 그런 근거로 사건을 할 수 있다고 생각하지 않습니다.

어쩌면 다른 사람들이이 도구에서 결함을 발견하는 경우, 나는 코믹하게 채택해야 할 강력한 이유가 있습니다.

  • 접근 방식을 변경해야합니다.
  • 귀하와 귀하의 팀은 다른 방식으로 일해야합니다.
  • 모든 변경의 영향을 자세하게 평가해야합니다.
  • 모든 변경 사항을 dem 등원 으로 만들도록 안내 합니다.

데이터베이스의 모든 변경 사항을 관리하는 프로젝트의 유일한 DBA 인 경우이 추론은 터무니없는 경계에 들리 듯합니다. 그러나 @BrentOzar가 요점을 가지고 있고 새로운 규칙 중 하나가 Everybody 's the DBA 라면 팀의 모든 개발자가 작업 할 수있는 방식으로 데이터베이스 변경을 제어해야합니다.

데이터베이스 프로젝트의 채택은 일부 개발자 에게 정신적 변화 ( 오래된 습관은 깨지기 어렵다 ) 또는 최소한 프로세스 나 워크 플로우의 변화를 요구할 수 있습니다 . 프로덕션 데이터베이스가 현재 버전의 데이터베이스를 나타내는 데이터베이스 응용 프로그램을 개발 한 개발자는 소스 코드가 데이터베이스를 변경하는 수단이되는 소스 코드 기반 접근 방식을 채택해야합니다 . Visual Studio 데이터베이스 프로젝트에서 프로젝트와 소스 코드는 데이터베이스 스키마에 대한 "진실의 한 버전"이며 개발자 또는 조직에서 응용 프로그램 스택의 다른 부분에 이미 사용중인 SCM 워크 플로를 사용하여 관리됩니다. 데이터의 경우 프로덕션 데이터베이스는 "단일 버전의 진실"로 유지됩니다.

데이터베이스 개발에 VS2010 접근 방식을 성공적으로 채택하는 데 필요한 근본적인 변화에 도달했습니다.

데이터베이스를 코드로 취급

더 이상 라이브 데이터베이스를 변경하지 않아도됩니다. 모든 데이터베이스 변경은 응용 프로그램 변경과 동일한 패턴을 따릅니다. 소스 수정, 빌드, 배포 이것은 Microsoft의 일시적인 방향 변경이 아니며 SQL Server의 미래입니다 . 코드로서의 데이터베이스 가 여기에 있습니다.

데이터베이스 개발자는 데이터베이스 엔진의 기존 오브젝트를 원하는 모양으로 변경하는 방법이 아니라 애플리케이션 버전의 오브젝트 모양을 정의합니다. 스스로 질문 할 수도 있습니다. 고객 테이블이 이미 포함 된 데이터베이스에 어떻게 배포됩니까? 여기에서 배치 엔진이 작동합니다. 앞에서 언급했듯이 배포 엔진은 컴파일 된 버전의 스키마를 가져 와서 데이터베이스 배포 대상과 비교합니다. 차이 엔진은 프로젝트에서 배포중인 버전과 일치하도록 대상 스키마를 업데이트하는 데 필요한 스크립트를 생성합니다.

예, 비슷한 패턴을 따르는 다른 도구가 있으며 대답에 대한 제약 조건을 벗어난 프로젝트의 경우 동등한 고려 가치가 있습니다. 그러나 Visual Studio 및 Team Foundation Server ALM을 사용하고 있다면 경쟁 할 수 없다고 생각합니다.

VS2010 데이터베이스 프로젝트에 어떤 문제가 있습니까?

편집 : 그럼 요점이 뭐야?

@AndrewBickerton은 원래 질문에 대답하지 않았다는 의견에서 "데이터베이스 개발에 SSMS 대신 Visual Studio 2010을 사용해야하는 이유는 무엇입니까?"라고 언급했습니다. 이리.

  • SSMS는 데이터베이스 개발 도구가 아닙니다. 예, SSMS를 사용하여 TSQL을 개발할 수 있지만 VS2010의 풍부한 IDE 기능을 제공하지는 않습니다.
  • VS2010은 데이터베이스를 코드로 취급하기위한 프레임 워크를 제공합니다.
  • VS2010은 데이터베이스 코드에 정적 코드 분석 을 제공합니다.
  • VS2010은 빌드-배포 테스트주기를 완전히 자동화 할 수있는 도구를 제공합니다.
  • SQL2012 및 Visual Studio vNext는 데이터베이스 프로젝트의 기능을 확장합니다. VS2010에 대해 지금 바로 익히고 차세대 데이터베이스 개발 도구를 시작하십시오.

몇 가지 경고와 함께 유용한 답변 : 1) 기준을 놓쳤다 "클라이언트 사이트로 전송되는 독립 실행 형 응용 프로그램을 개발 중입니다 (예 : 생성 된 야생 및 새로운 [비어있는] 데이터베이스에 동일한 데이터베이스의 여러 복사본이 있음) / 항상 판매) ") 2) 데이터베이스를 코드로 취급하고 개발, 빌드, 배포주기 (이미 동의 한)를 관리해야하는 이유에 대해 답변했습니다. VS2010을 그 메커니즘으로 사용해야하는 이유에 대한 설득력있는 이유는 없습니다. +2 (사려 깊은 대답) -1 (실제 질문에 대답하지 않음)
앤드류 비 커튼

2
SQL 스크립트에 어떤 "풍부한 IDE"가 필요합니까?
gbn

1
자동화 된 빌드-배포-테스트주기의 이점은 다운 스트림에 있습니다. 라이브 배포의 자동화 된 부분은 "수동"(즉, 수동 단계가 필요 없음)으로 제한됩니다.
Mark Storey-Smith

1
그 외에도 통합에 대한 귀하의 주장에는 몇 가지 장점이 있습니다. 일반적인 경우에 얼마나 잘 작동합니까? 나는 그것에 문제가 있었지만, 그것이 작동하도록 할 수 있다고 감히.
ConcernedOfTunbridgeWells

2
내가 :-) 당신을 위해 그것을 할 것 @Nick
잭 더글라스

7

SSMS를 모르거나 타사 도구를 사용한 경우 VS가 멋지게 보일 수 있습니다. 스키마 비교 등에 Red Gate 도구를 사용하면 무료 SSMS 플러그인도 VS의 격차가 두드러집니다.

소스 제어 비트가 잘못되었습니다. 프로덕션 데이터베이스에있는 것은 참조 사본입니다. 개발자가 사용하고있는 것이 아닙니다. 보다


1
VS2010으로 DB 디자인 / 개발 및 스키마 관리를 수행 할 수는 있지만이 방법으로 더 나은 타사 툴 체인이 있습니다.
ConcernedOfTunbridgeWells

1
왜 프로덕션을 참조 사본으로 사용 하시겠습니까? 나는 이것이 나쁜 습관이라고 생각하며 아마도 소스 컨트롤이 손상되었다는 신호 일 수도 있습니다. 데이터베이스 코드가 다른 모든 것과 마찬가지로 개발 수명주기에 속하지 않아야하는 이유는 무엇입니까?
Nick Chammas

@NickChammas : 프로덕션의 복원 본을 의미합니다. 현재 상점에서 소스 제어의 내용이 라이브 DB와 일치하지 않습니다. 마지막으로 다른 팀과 비슷합니다. 변경 스크립트를 통해 배포되는 것은 개발자가 작업하는 것이 아닙니다.
gbn

6

SSRS 보고서 디자인 및 SSIS 패키지에 Visual Studio (BIDS)를 광범위하게 사용합니다. Management Studio에서 전혀 잘 할 수 없었습니다. Visual Studio는 훨씬 더 완전하고 통합 된 개발 환경이며 소스 제어 시스템에도 훨씬 더 적합합니다. 그리고 그것은 가격에 모두 반영됩니다!


6

솔직히 말해서, 투표는 데이터베이스 디자인, 개발 및 (분명히) 관리를 위해 SQL Server Management Studio에 직접 전달됩니다. 입력하는 것이 더 쉽습니다.

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

그런 다음 모든 올바른 장소를 클릭하십시오. SSMS는 훌륭한 레이아웃이자 작업에 절대적으로 도움이됩니다. 저는 기본적으로 .NET 소프트웨어 개발자입니다. 그러나 데이터베이스 디자인 및 코딩에 관해서는 SSMS를 10 중 11 번 선택합니다.


Visual Studio에서는 테이블 DDL을 정확히 같은 방식으로 입력합니다. 당신은 다른 것을 생각하고 있습니까?
Nick Chammas

1
@ Nick 아마 그 말을 잘못했을 것입니다. 나는 VS에서 그렇게 할 수 있다는 것을 알고 있지만, 내 일은 내 특정 작업 (및 큰 작업)을위한 전용 도구를 갖는 것이 좋습니다. 나는 분명히 습관의 짐승이며 SSMS를 내 습관으로 만들었습니다. :)
Thomas Stringer

2
정말? SSMS 솔루션 / 프로젝트 기능은 출시 2 주 전에 인턴이 추가 한 것처럼 느껴집니다.
Mark Storey-Smith

1
@ MarkStorey-Smith는 SSMS가 실제로 프로젝트 / 솔루션 지원을 제공하지 않는 방법에 대한 질문이며 팀 전체의 IDE에서 팀이 잘 작동하도록하는 데 중요합니까?
jcolebrand

3
하나의 라이너는 SSMS가 데이터베이스 관리 도구이고 VS2010이 데이터베이스 개발 도구라는 것입니다.
Mark Storey-Smith

5

모범 사례는 없지만 VS 2010 데이터베이스 프로젝트 및 소스 코드 컨트롤러 (VSS 2010, Subversion 등)를 사용하면 데이터베이스 버전을 지정할 수 있습니다.

먼저 데이터베이스를 SSMS에 직접 디자인하는 것이 좋습니다. 데이터베이스가 거의 준비되면 VS 2010 데이터베이스 프로젝트로 가져옵니다. 가져 오기가 완료되면 모든 수정 사항을 추적하기 위해 항상 데이터베이스 프로젝트에 새 스크립트를 추가해야합니다. 데이터베이스 프로젝트의 비교 기능을 사용하여 개발 서버에서 모든 변경 사항을 가져오고 해당 스크립트를 모두 프로젝트로 직접 가져올 수 있습니다. 이제 소스 코드 컨트롤러로 변경 사항을 "커밋"하면됩니다.

이 방법을 사용하면 버전이 지정된 데이터베이스를 가질 수 있습니다. 각 수정 버전을 확인하고 변경 사항을 롤백 할 수 있습니다.

이것이 유일한 장점은 아닙니다. 이러한 종류의 프로젝트를 사용하면 변경 내용을 스크립팅하기 위해 모든 데이터베이스를 프로젝트와 비교하고 SQL PowerShell 명령 프롬프트를 사용하여 모든 스크립트를 동일한 스크립트로 업데이트 할 수 있습니다.이 스크립트는 데이터베이스의 XML 스키마입니다. 데이터베이스를 업데이트하는 데 필요한 명령 만 실행합니다. 당신은 또한 할 수있는 가능성이 단위 테스트를 데이터베이스에 있습니다. 데이터베이스 프로젝트에 대한 다른 좋은 기사는 여기에 있습니다 . 배포 기능을 사용하면 사전 스크립트 및 사후 스크립트를 가질 수 있습니다. 이러한 스크립트를 사용하면 시스템 테이블에 데이터를 검증하거나 삽입 할 수 있습니다.

데이터베이스 프로젝트를위한 단계별 절차는 다음과 같습니다 .


4
이것은 VS2010에서 데이터베이스 개발을 수행하는 방법이 아니며, 요점을 다소 놓친 것으로 보입니다. 1) SSMS에서 그린 필드 데이터베이스를 디자인 한 다음 VS로 가져 오는 이유는 무엇입니까? 2) 변경 사항을 추적하기 위해 "항상 데이터베이스 프로젝트에 새 스크립트를 추가"할 필요는 없습니다. 3) 스크립트는 데이터베이스의 "xml 스키마"가 아닙니다.
Mark Storey-Smith

데이터베이스 프로젝트를 사용해 본 적이 있습니까? 1-데이터베이스를 한 번만 가져올 수 있으므로 모든 스크립트를 작성하지 않으려면 데이터베이스의 첫 번째 초안에 대해 SSMS에서 가능한 최대 값을 수행하십시오. 2- VS2010의 비교 도구를 사용하여 변경 사항을 추적 할 수 있으며 VS2010이이를 변경합니다. 3- 데이터베이스 프로젝트를 사용해보십시오. 데이터베이스 프로젝트를 배포 할 때 프로덕션 데이터베이스를 최신 상태로 유지하기 위해 데이터베이스의 XML 스키마를 얻게됩니다.
니코

2
그렇습니다. 초기와 더 고통스러운 버전부터 . 당신은 참으로 일단 가져올 것입니다하지만 당신은 (당신이 이제까지 것이없는 많은 동기화 이 환경의 작업 외부를 계속하지 않는 한, 그렇게하도록). 'XML Schema'스크립트라고하는 것에 대한보다 정확한 설명은 도구가 데이터베이스의 xml 기반 메타 모델을 유지 관리한다는 것인데, 명령 행 배치 도구는 대상 데이터베이스를 업데이트하는 데 필요한 명령을 작성하는 데 사용합니다. .
Mark Storey-Smith

2

SQL Server를 설치할 때 SSMS가 있기 때문에 VS2010보다 SSMS를 더 많이 사용합니다. 이것이 아마도 SSMS가 VS2010, IMHO보다 더 많이 사용되는 이유 일 것입니다.

또한 Red-Gate와 같은 공급 업체가 반드시 VS2010이 아닌 SSMS와 통합되는 도구를 개발하고 있음을 발견했습니다. 이는 Microsoft가 아닌 SSMS를 개선 할 수 있다는 점에서 긍정적일 수 있습니다. 이에 대한 한 가지 예는 Red-Gate의 SQL 소스 제어입니다. SSMS의 추가 기능으로 SSMS를 회사의 소스 제어 시스템에 Visual Team Foundation이든 상관없이 연결할 수 있습니다. VS2010에는 내장 기능이 있지만 Reg-Gate 도구의 가격과 비교하여 VS2010을 구입하지 않고도 많은 돈을 절약했습니다.

나는 전반적으로 그것이 선호에 달려 있다고 생각합니다. 당신이 편한 것을 가지고 일합니다. 새로운 사람을 훈련시키고 VS2010에서 그들을 훈련 시키면 그들은 그것을 좋아하는 방법을 알고 있기 때문에 그들의 선호가 될 것입니다.

SQL Server 2012로 게임을 시작한 경우 SSMS가 VS2010의 구성을 느리지 만 확실하게 얻는 것을 알 수 있습니다. 결국에는 차이점을 구분하지 못할 수도 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.