나는이 질문이 처음 게시 된 이후 로이 질문에 대한 답변을 구성하는 방법에 대해 이야기하고 있습니다. VS2010의 경우 도구의 기능과 이점을 설명하지 않기 때문에 어렵습니다. 이것은 독자가 데이터베이스 개발에 대한 접근 방식을 근본적으로 바꾸도록 설득하는 것입니다. 쉬운 일이 아닙니다.
DBA, 개발자 / dba 및 OLTP 및 데이터웨어 하우징에 걸친 배경 구성을 갖춘 노련한 데이터베이스 전문가의이 질문에 대한 답변이 있습니다. 데이터베이스 개발의 모든 측면에 대해 이것에 접근하는 것은 불가능합니다. 그래서 특정 시나리오에 대해 시도하고 사례를 만들 것입니다.
귀하의 프로젝트가 이러한 기준에 부합한다면 VS2010에 대한 매력적인 사례가 있다고 생각합니다.
- 팀에서 응용 프로그램 개발에 VS2010을 사용하고 있습니다.
- 팀에서 소스 제어 및 빌드 관리에 TFS를 사용하고 있습니다.
- 데이터베이스가 SQL Server입니다.
- 귀하의 팀은 이미 VS 자동 테스트를 받았거나 관심이 있습니다.
데이터베이스 개발을 위해 VS2010을 평가 하는 경우 Visual Studio ALM Rangers 의 Visual 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에 대해 지금 바로 익히고 차세대 데이터베이스 개발 도구를 시작하십시오.