SSDT 및 Visual Studio 2012 데이터베이스 프로젝트로 데이터베이스 배포를 올바르게 관리하는 방법은 무엇입니까?

Question

저는 기존의 소규모 프로젝트에서 2012 데이터베이스 프로젝트를 채택하려는 연구 단계에 있습니다. 저는 C# 개발자이고 DBA가 아니므로 모범 사례에는 유창하지 않습니다. 몇 시간 동안 Google과 stackoverflow를 검색했지만 지금도 몇 가지 주요 배포 시나리오를 올바르게 처리하는 방법을 알지 못합니다.

1) 여러 개발주기 동안 내 데이터베이스의 여러 버전을 어떻게 관리합니까? 내 데이터베이스의 v3에 클라이언트가 있는데이를 v8로 업그레이드하려면 어떻게해야합니까? 현재 Google은 모든 버전의 제품에 대해 수작업으로 작성한 스키마 및 데이터 마이그레이션 스크립트를 관리합니다. 이 작업을 별도로 수행해야합니까, 아니면이를 지원하거나 대체하는 새로운 패러다임에 뭔가가 있습니까?

2) 데이터를 이동해야하는 방식으로 스키마가 변경되면이를 처리하는 가장 좋은 방법은 무엇입니까? 일부 작업은 데이터를 보존하기 위해 배치 전 스크립트에서 처리 된 것으로 가정하고 배치 후 스크립트는 올바른 위치에 다시 배치합니다. 그게 그 길인가, 아니면 더 나은 것이 있습니까?

3) 이러한 새로운 기술을 사용하는 최선의 방법에 대한 다른 조언이나 조언도 대단히 감사하겠습니다!

업데이트 : 원래이 질문을 던지고 문제 해결에 대한 생각이 들기 시작한 이래로 문제에 대한 이해가 조금씩 늘어났습니다.하지만 내가 바라는 해결책은 아니 었습니다. 여기에 내 문제의 rewording가 :

내가 가지고있는 문제는 순전히 데이터 관련 있습니다. 내 응용 프로그램의 버전 1에 클라이언트가 있고 응용 프로그램의 버전 5로 업그레이드하려는 경우 해당 데이터베이스에 데이터가없는 경우 아무런 문제가 없습니다. SSDT가 지능적으로 스키마를 비교하고 데이터베이스를 한 번에 마이그레이션 할 수 있도록합니다. 불행히도 클라이언트는 데이터를 가지고 있으므로 그렇게 간단하지 않습니다. 내 애플리케이션의 버전 1에서 버전 2 (버전 3) 로의 스키마 변경은 모두 데이터에 영향을줍니다. 데이터 관리를위한 현재의 전략에는 각 버전 업그레이드 (1 ~ 2, 2 ~ 3 등)에 대한 스크립트를 유지해야합니다. 이렇게하면 곧바로 갈 데이터 이전 스크립트가 없기 때문에 응용 프로그램의 버전 1에서 버전 5로 직선 이동하지 못하게됩니다. 모든 클라이언트에 대해 사용자 지정 업그레이드 스크립트를 작성하거나 모든 버전에서 모든 버전으로 업그레이드 스크립트를 관리하는 전망은 기하 급수적으로 관리하기 어렵습니다. 내가 바라는 점은 사물의 데이터면을 쉽게 관리 할 수있게 해주는 SSDT를 가능케하는 일종의 전략이 있다는 것입니다. 사물의 스키마 측면만큼이나 쉬울 수도 있습니다. SSDT에 대한 나의 최근 경험은 나에게 그런 전략에 대한 어떤 희망도주지 않았지만 나는 다른 것을 찾아 내고 싶다.

Answer 1

나는이에 자신을 일하고 있었고, 나는 그것이 쉬운 일이 아닙니다 말할 수 JT.

먼저 JT에 의한 회신을 처리하기 위해 SSDT에있는 선언적 업데이트 기법을 사용하는 경우에도 "버전"을 삭제할 수 없습니다. SSDT는 소스 스키마를 모든 대상 스키마로 이동하는 "꽤 괜찮은"작업 (모든 스위치와 잡다한 점을 알고 있어야 함)을 수행합니다. 실제로이 작업을 직접 수행 할 필요는 없지만 " 데이터 모션 "(적어도 내가 볼 수있는!). 따라서 DBProj와 마찬가지로 사전/사후 스크립트에서 자신의 장치로 이동했습니다. 데이터 모션 스크립트는 알려진 시작 및 끝 스키마 상태에 의존하기 때문에 DB의 버전 관리를 피할 수 없습니다. 따라서 "데이터 동작"스크립트는 스키마의 버전이있는 스냅 샷에 적용되어야합니다. 즉, v1에서 v8으로 임의로 DB를 업데이트 할 수 없으며 데이터 모션 스크립트 v2에서 v8이 작동 할 것으로 기대할 수 있습니다 (아마, v1 데이터 모션 스크립트 필요).

슬프게도 통합 시나리오에서이 시나리오를 처리 할 수있는 SSDT 게시의 메커니즘을 볼 수 없습니다. 즉, 자신의 scafolding을 추가해야합니다.

첫 번째 트릭은 데이터베이스 (및 SSDT 프로젝트) 내에서 버전을 추적하는 것입니다. 나는 DBProj에서 트릭을 사용하기 시작했고 SSDT로 가져 왔고 몇 가지 조사를 한 후에 다른 사람들도 이것을 사용하고있는 것으로 나타났습니다. DB 확장 속성을 데이터베이스 자체에 적용 할 수 있습니다 ("BuildVersion"또는 "AppVersion"또는 이와 비슷한 이름으로 지정). 버전 값을 적용합니다. 그런 다음 SSDT 프로젝트 자체에서이 확장 속성을 캡처 할 수 있으며 SSDT는이 속성을 스크립트로 추가합니다 (확장 속성이 포함 된 게시 옵션을 확인할 수 있음). 그런 다음 SQLCMD 변수를 사용하여 현재 패스에 적용되는 소스 및 대상 버전을 식별합니다.원본 (프로젝트 스냅 샷)과 대상 (업데이트 할 대상 db) 간의 버전 차이를 확인하면 적용해야하는 모든 스냅 샷을 찾을 수 있습니다. 안타깝게도 에서 SSDT 배포를 수행하는 것이 까다로 우며,이를 빌드 또는 배포 파이프 라인으로 옮겨야 할 것입니다. (우리는 TFS 자동화 된 배포를 사용하고 이에 대한 사용자 지정 작업이 있습니다.)

다음 장애물은 스키마의 스냅 샷과 관련 데이터 모션 스크립트를 유지하는 것입니다. 이 경우 스크립트를 가능한 한 멱등수로 만드는 것이 좋습니다. 즉, 부작용없이 스크립트를 재실행 할 수 있습니다. 한 번만 실행해야하는 스크립트에서 안전하게 다시 실행할 수있는 스크립트를 분리하는 데 도움이됩니다. 정적 참조 데이터 (사전 또는 조회 테이블)를 사용하여 동일한 작업을 수행합니다. 즉, 참조 데이터를 동기화 상태로 유지하는 MERGE 스크립트 라이브러리 (테이블 당 하나)가 있으며이 스크립트는 게시물에 포함됩니다 -deployment scripts (SQLCMD : r 명령을 통해). 여기서 중요한 점은 은 이러한 참조 테이블에 서로 FK 참조가있는 경우 올바른 순서로 실행해야한다는 것입니다. 이 스크립트를 주 배포 후 스크립트에 순서대로 포함 시키며 이러한 스크립트를 생성하는 도구를 만든 다음 종속성 순서를 해결하는 데 도움이됩니다. 정적 참조 데이터의 현재 상태를 캡처하기 위해 "버전"을 닫은 상태에서이 생성 도구를 실행합니다. 모든 다른 데이터 모션 스크립트는 기본적으로 특수한 경우가 될 것이며 대부분 단일 용도로만 사용됩니다. 이 경우 db build/app 버전에 대해 IF 문을 사용하거나 각 스냅 샷 패키지를 만든 후 1 시간 스크립트를 지울 수 있습니다.

SSDT는 FK 검사 제약 조건을 해제하고 배포 후 스크립트를 실행 한 후에 만 ​​다시 활성화한다는 것을 기억하십시오. 예를 들어 새로운 null이 아닌 필드를 채울 수있는 기회를 제공합니다. (그런데이 옵션을 사용하면 null이 아닌 열에 대한 임시 "스마트"기본값을 생성해야합니다.) 그러나 FK 검사 제약 조건은 스키마 변경으로 인해 SSDT가 다시 작성하는 테이블에 대해서만 비활성화됩니다. 다른 경우에는 데이터 모션 스크립트가 점검 제약 불만을 피하기 위해 올바른 순서로 실행되는지 (또는 스크립트에서 수동으로 비활성화/다시 활성화해야하는지) 책임을집니다.

DACPAC은 기본적으로 스냅 샷이기 때문에 DACPAC이 도움이 될 수 있습니다. 스키마 (프로젝트의 빌드 출력과 유사)를 설명하는 XML 파일이 여러 개 있지만 프로젝트를 만든 순간 정시에 고정됩니다. 그런 다음 SQLPACKAGE.EXE 또는 배포 공급자를 사용하여 해당 패키지 스냅 샷을 게시 할 수 있습니다. DACPAC 버전 관리 방법을 "등록 된"데이터 응용 프로그램과 더 관련이 있기 때문에 파악하지 못했습니다. 따라서 우리는 자체 버전 관리 체계를 고수하고 있지만 DACPAC 파일 이름에 자체 버전 정보를 넣습니다.

내가 제공 할 결론적 인 사례가 더 있었으면 좋겠다.하지만 여기서도 문제를 해결하고 있습니다.

SSDT에 대해 정말 짜증 나는 점 중 하나는 DBProj와 달리 현재 확장이 불가능하다는 것입니다. 많은 다른 것들에서 DBProj보다 훨씬 훌륭하게 작업을 수행 할 수 있지만 문제를 해결하기위한 사전/사후 스크립트의 일부 방법을 찾을 수 없다면 기본 동작을 재정의 할 수 없습니다. 현재 해결해야 할 문제 중 하나는 수천만 개의 레코드가있을 때 CCDR (테이블 업데이트)을 다시 만드는 기본 방법이 실제로 악취를내는 것입니다.

- UPDATE : 나는이 게시물을 언젠가는 보지 못했지만 최근에 활동적 이었으므로 몇 가지 중요한 메모를 추가 할 것입니다. VS2012를 사용한다면 2013 년 6 월 SSDT 이제 데이터 비교 도구가 내장되어 있고 확장 점도 제공됩니다. 즉, 프로젝트에 대한 Build Contributors와 Deployment Plan Modifiers를 포함 할 수 있습니다.

Answer 2

나는이 주제에 대해 더 이상 유용한 정보를 찾지 못했지만 툴을 알고, 땜장이를하고, 놀면서 시간을 보냈다. 나는 내 질문에 대한 몇 가지 대답을 생각해 냈다. 이것들이 반드시 최선의 해답은 아닙니다. 이러한 시나리오를보다 잘 지원할 수있는 다른 방법이나 모범 사례가 있는지는 아직 알 수 없지만 여기에 나와있는 내용이 있습니다.

특정 버전의 데이터베이스에 대한 사전 및 사후 배포 스크립트는 다음과 같습니다. 이전 버전의 데이터 만 마이그레이션합니다. 모든 개발주기가 시작될 때 스크립트는 제거되고 개발이 진행됨에 따라 이전 버전의 데이터를 새 버전으로 안전하게 마이그레이션하는 데 필요한 sql이 필요합니다. 한 가지 예외는 데이터베이스의 정적 데이터입니다. 이 데이터는 디자인 타임에 알려져 있으며 T-SQL MERGE 문 형태로 배포 후 스크립트에 영구적으로 존재합니다. 이렇게하면 최신 게시 스크립트만으로 모든 버전의 데이터베이스를 새로운 환경에 배포 할 수 있습니다. 모든 개발주기가 끝나면 이전 버전에서 새 버전으로 게시 스크립트가 생성됩니다. 이 스크립트는 생성 된 sql을 포함하여 스키마와 손으로 만들어진 배포 스크립트를 마이그레이션합니다.예, 게시 도구는 데이터베이스에 대해 직접 사용될 수 있지만 클라이언트에게는 좋은 옵션이 아닙니다. 나는 또한 dacpac 파일을 알고 있지만 실제로 사용하는 방법을 잘 모르겠습니다. 생성 된 게시 스크립트가 프로덕션 업그레이드에 대해 알고있는 최선의 옵션 인 것 같습니다.

그래서 답변을 내 시나리오 :

1) V8에 V3에서 데이터베이스를 업그레이드하려면, 나는 V6를 위해 다음 V5에 대한 다음, V4를 위해 생성 된 게시 스크립트를 실행해야 할 것 등이 매우이다 지금 우리가하는 방식과 비슷합니다. 그것은 잘 이해하고 데이터베이스 프로젝트는 훨씬 쉽게 스크립트를 생성/유지하는 것으로 보인다.

2) 스키마가 아래의 데이터에서 변경되면 배포 전 및 배포 후 스크립트를 사용하여 데이터를 새 버전으로 이동해야하는 위치로 마이그레이션합니다. 영향을받는 데이터는 기본적으로 사전 배포 스크립트에서 백업되고 사후 배포 스크립트의 제자리에 저장됩니다.

3)이 시나리오와 다른 도구에서 이러한 도구를 사용하는 것이 가장 좋은 방법에 대한 조언을 찾고 있습니다. 여기에 잘못된 것이 있거나 내가 알아야 할 다른 문제가 있다면 알려 주시기 바랍니다! 감사!

Answer 3

내 SSDT 사용 경험에서 데이터베이스 (예 : v1, v2 ... vX 등)에 대한 버전 번호 개념은 사라집니다. 이것은 SSDT가 선언적 데이터베이스 개발로 알려진 개발 패러다임을 제공하기 때문에, 당신이 당신의 스키마를 원하는 상태를 SSDT에게 말한 다음 SSDT가 이미 가지고있는 것과 비교함으로써 그 상태로 가져 오는 책임을지게한다는 것을 의미합니다. 이 패러다임에서 v4를 배포 한 다음 v5 등의 개념이 사라집니다.

올바른 상태로 데이터를 관리하기 위해 사전 및 사후 배포 스크립트가 있습니다.

희망이 있습니다.

Answer 4

지금까지이 스레드가 지금까지 훌륭하다고 말하고 싶었습니다.

나는 똑같은 문제에 대해 씨름 해 왔으며 상당히 큰 레거시 응용 프로그램에서 우리 조직에서이 문제를 해결하려고 시도하고 있습니다. SSDT (TFS 지점)로 이동하는 과정을 시작했지만 배치 과정을 이해하고 사용자 지정 마이그레이션 및 참조/조회 데이터를 관리해야합니다.

우리의 응용 프로그램은 하나의 코드베이스이지만 '고객'별로 사용자 정의 할 수 있으므로 우리는이 프로젝트에서 약 190 개 정도의 데이터베이스를 처리합니다. . 우리는 항상 배치를 수행하고 새로운 고객을 공정하게 설치합니다. 우리는 이전 버전의 점진적인 릴리스 스크립트 (및 해당 버전에서 새 고객을 만들기위한 스크립트)를 사용하여 PowerShell에 크게 의존합니다. 우리가이 모든 것을 파악한 후에는 기부 할 계획이지만, 배운 내용을 공유하십시오. 나는 버전마다 커스텀 릴리스 스크립트를 유지할 것이라고 믿지만, 우리는 보게 될 것이다. 프로젝트 내에서 각 스크립트를 유지 관리하고 From 및 To SqlCmd 변수를 포함하는 것에 대한 아이디어는 매우 흥미 롭습니다. 우리가 그렇게했다면, 우리는 아마도 그 길을 지나치게 잘라 버렸을 것입니다. 물리적으로 오래된 업그레이드 스크립트를 삭제하면 모두가 그 버전을지나 가게됩니다.

BTW - 사이드 노트 - 낭비를 최소화하기위한 주제로, 열에 적절한 명명/데이터 형식 규칙을 적용하는 방법을 자동화하는 방법과 모든 기본 및 자동 생성 규칙을 자동 생성하는 방법에 대해 알아 보았습니다. 외래 키, 명명 규칙, 색인 및 검사 제약 조건 등을 기반으로합니다. 가장 어려운 부분은 규칙을 따르지 않은 '편차'를 처리하는 것이 었습니다. 관심있는 사람이 있으면 언젠가 나눌 것입니다.하지만 지금은이 배포, 마이그레이션 및 참조 데이터 스토리를 집중적으로 추구해야합니다. 다시 한번 감사드립니다. 너희들이 내 머리 속에있는 것을 정확히 말하고서 오늘 아침을 찾고 있었던 것과 같다.