it-swarm-ko.tech

소스 제어의 스토어드 프로 시저 / DB 스키마

선택한 소스 제어 시스템에서 저장 프로 시저 및 데이터베이스 스키마를 추적합니까?

변경 (테이블 추가, 저장 프로 시저 업데이트)을 수행 할 때 소스 제어로 변경 사항을 가져 오려면 어떻게해야합니까?

우리는 직장에서 SQL Server를 사용하고 버전 관리를 위해 darcs를 사용하기 시작했지만 일반적인 전략과 편리한 도구에 대해 궁금합니다.

Edit :와, 모든 훌륭한 제안에 감사드립니다. 하나 이상의 "허용 된 답변"을 선택할 수 있기를 바랍니다!

68
Dana

우리는 모든 것을 스크립팅하기로 선택했으며 여기에는 모든 저장 프로 시저 및 스키마 변경이 포함됩니다. wysiwyg 도구가 없으며 멋진 '동기화'프로그램이 필요하지 않습니다.

스키마 변경은 쉽습니다. 모든 스키마 및 데이터 변경을 포함하여 해당 버전에 대한 단일 파일을 만들고 유지하기 만하면됩니다. 버전 x에서 x + 1 로의 변환 스크립트가됩니다. 그런 다음 프로덕션 백업에 대해이를 실행하고이를 '일별 빌드'에 통합하여 오류없이 작동하는지 확인할 수 있습니다. 나중에 작성된 SQL을 중단시킬 수 있으므로 이미 작성된 스키마/데이터로드 SQL을 변경하거나 삭제하지 않는 것이 중요합니다.

-- change #1234
ALTER TABLE asdf ADD COLUMN MyNewID INT
GO

-- change #5678
ALTER TABLE asdf DROP COLUMN SomeOtherID
GO

저장 프로 시저의 경우 sproc 당 단일 파일을 선택하고 삭제/만들기 양식을 사용합니다. 모든 저장 프로시 저는 배포시 다시 생성됩니다. 단점은 소스 컨트롤 외부에서 변경을 수행하면 변경 내용이 손실된다는 것입니다. 동시에, 그것은 모든 코드에 해당되지만 DBA는 이것을 알고 있어야합니다. 업그레이드하면 변경 사항이 손실되므로 팀 외부의 사람들이 저장 프로 시저로 뭉개지는 것을 실제로 막습니다.

Sql Server를 사용하는 구문은 다음과 같습니다.

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[usp_MyProc]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)
drop procedure [usp_MyProc]
GO

CREATE PROCEDURE [usp_MyProc]
(
    @UserID INT
)
AS

SET NOCOUNT ON

-- stored procedure logic.

SET NOCOUNT OFF

GO  

남은 것은 모든 개별 파일을 대조하고 전체 업데이트 세트 (단일 스크립트)로 새 파일을 작성하는 유틸리티 프로그램을 작성하는 것입니다. 먼저 스키마 변경 사항을 추가 한 후 디렉토리 구조를 반복하고 모든 스토어드 프로 시저 파일을 포함하여이를 수행하십시오.

모든 것을 스크립팅하는 것에 대한 거꾸로 SQL을 읽고 쓰는 것이 훨씬 나아질 것입니다. 이 전체 프로세스를보다 정교하게 만들 수도 있지만 이것은 특별한 소프트웨어없이 모든 SQL을 소스 제어하는 ​​기본 형식입니다.

부록 : Rick은 DROP/CREATE를 사용하여 저장 프로 시저에 대한 사용 권한을 잃는 것이 맞으므로 특정 권한을 다시 활성화하는 다른 스크립트를 작성해야 할 수도 있습니다. 이 권한 스크립트는 마지막으로 실행됩니다. 우리의 경험은 ALTER verses DROP/CREATE 시맨틱과 관련된 더 많은 문제를 발견했습니다. YMMV

43
Robert Paulson

visual Studio에서 "데이터베이스 프로젝트"를 작성하여 sQL 코드를 작성 및 관리하고 프로젝트를 나머지 솔루션과 함께 버전 제어 상태로 유지하십시오.

8
Manu

마지막 작업에서 사용한 솔루션은 스크립트가 소스 제어에 추가 될 때 스크립트에 번호를 매기는 것입니다.

01. CreateUserTable.sql
02.PopulateUserTable
03.AlterUserTable.sql
04.CreateOrderTable.sql

아이디어는 스크립트를 실행할 순서를 항상 알고 있었으므로 스크립트 # 1을 수정하려고 할 때 발생할 수있는 데이터 무결성 문제를 관리하지 않아도된다는 것입니다 (# 2의 INSERT가 실패 할 수 있음).

8
japollock

Robert Paulson의 관행에 동의합니다. 그것은 당신이 그러한 관행을 고수 할 책임과 규율을 가지고 개발 팀을 통제하고 있다고 가정합니다.

이를 팀에 "강제"하기 위해 Google 솔루션은 Visual Studio Team Edition for Database Professionals에서 하나 이상의 데이터베이스 프로젝트를 유지 관리합니다. . 솔루션의 다른 프로젝트와 마찬가지로 데이터베이스 프로젝트는 버전 관리를받습니다. 데이터베이스의 모든 것을 유지 관리 가능한 덩어리로 나누는 과정에서 자연스러운 방식으로 팀을 "훈련"합니다.

물론 Visual Studio 프로젝트이기 때문에 완벽한 곳은 아닙니다. 좌절하거나 혼동을 줄 수있는 많은 문제가 있습니다. 작업을 수행하기 전에 프로젝트의 작동 방식을 이해해야합니다. 예를 들어

그러나 데이터베이스 객체의 버전을 관리하지 않는 팀에게는 이것이 좋은 시작입니다. 다른 유명한 대안은 물론 Red Gate의 SQL Server 제품 제품군 입니다.이 제품을 사용하는 대부분의 사람들은 Microsoft 제품보다 우수하다고 생각합니다.

5
icelava

SQL Server의 드롭/생성 스크립트와 관련하여 명심해야 할 것은 개체 수준 권한이 손실된다는 것입니다. 대신 ALTER 스크립트를 사용하도록 표준을 변경하여 해당 권한을 유지합니다.

객체를 삭제하면 sp_depends에서 사용하는 종속성 레코드가 삭제되고 객체를 만들면 해당 객체에 대한 종속성 만 생성된다는 사실과 같은 몇 가지주의 사항이 있습니다. 따라서 뷰를 삭제/만들면 sp_depends는 더 이상 해당 뷰를 참조하는 객체를 알 수 없습니다.

이야기의 도덕은 ALTER 스크립트를 사용하십시오.

5
Rick

저장 프로 시저를 포함하여 데이터베이스를 자동으로 설정하는 스크립트를 작성해야한다고 생각합니다. 그런 다음이 스크립트를 소스 제어에 배치해야합니다.

4
Adrian Mouat

내 경험과 다른 관점. 오라클 세계에서는 모든 것이 "만들기"DDL 스크립트로 관리되었습니다. ahockley가 언급했듯이 각 객체마다 하나의 스크립트가 있습니다. 객체를 변경해야하는 경우 해당 DDL 스크립트가 수정됩니다. 모든 객체 스크립트를 호출하는 하나의 래퍼 스크립트가 있으므로 현재 DB 빌드를 원하는 환경에 배포 할 수 있습니다. 이것은 주요 코어 생성을위한 것입니다.

라이브 응용 프로그램에서 새 열이 필요한 새 빌드를 푸시 할 때마다 테이블을 삭제하고 새로 만들지 않습니다. ALTER 스크립트를 수행하고 열을 추가합니다. 따라서 이러한 종류의 변경이 발생할 때마다 항상 두 가지 작업을 수행해야합니다. 1) alter DDL을 작성하고 2) 핵심 변경 DDL을 변경하여 변경 사항을 반영합니다. 둘 다 소스 제어에 들어가지만 단일 변경 스크립트는 델타를 적용하는 데만 사용되므로 시간 변경 시점에 더 가깝습니다.

ERWin과 같은 도구를 사용하여 모델을 업데이트하고 DDL을 앞으로 생성 할 수도 있지만, 알고있는 대부분의 DBA는 스크립트를 원하는 방식으로 정확하게 생성하는 모델링 도구를 신뢰하지 않습니다. ERWin을 사용하여 핵심 DDL 스크립트를 주기적으로 모델로 리버스 엔지니어링 할 수도 있지만, 제대로 보이게하려면 많은 시간이 필요합니다.

Microsoft 세계에서도 비슷한 전술을 사용했지만 Red Gate 제품을 사용하여 스크립트와 델타를 관리했습니다. 여전히 스크립트를 소스 제어에 두십시오. 객체 당 여전히 하나의 스크립트 (테이블, sproc 등) 처음에 일부 DBA는 스크립트를 사용하는 대신 SQL Server GUI를 사용하여 개체를 관리하는 것을 선호했습니다. 그러나 기업 성장에 따라 일관되게 관리하기가 매우 어려웠습니다.

DDL이 소스 제어에있는 경우, 빌드 스크립트 (일반적으로 개미)를 사용하여 배치 스크립트를 작성하는 것은 쉽지 않습니다.

3
Ed Lucas

지금까지 가장 쉽고 빠르며 안전한 방법은 총알을 물고 RedGate의 SQL Source Control을 사용하는 것입니다. 몇 분 안에 스크립트를 작성하고 저장소에 저장합니다. RedGate가이 제품을 손실의 리더로보고 더 널리 사용하기를 바랍니다.

3
anopres

과거의 경험에서, 나는 제품의 각 릴리스마다 데이터베이스 변경 사항이 항상 스크립트 작업을 수행하고 우리가 작업중인 릴리스에 저장되도록 데이터베이스 변경 소스를 제어했습니다. 구축 프로세스는 각 "응용 프로그램"에 대한 현재 버전을 저장 한 데이터베이스의 테이블을 기반으로 데이터베이스를 현재 버전으로 자동 가져옵니다. 우리가 작성한 사용자 지정 .net 유틸리티 응용 프로그램은 데이터베이스의 현재 버전을 실행 및 결정하고 스크립트의 접두사 번호 순서로 새 스크립트를 실행합니다. 그런 다음 모든 것이 제대로 작동하는지 확인하기 위해 단위 테스트를 실행했습니다.

다음과 같이 소스 제어에 스크립트를 저장합니다 (아래 폴더 구조).

나는 테이블과 저장 프로 시저에 대한 현재 명명 규칙에 약간의 녹슬 었습니다.

[뿌리]
[신청]
[버전]
[스크립트]

\ 스크립트
내 응용 프로그램\
1.2.1 \
001.MyTable.Create.sql
002.MyOtherTable.Create.sql
100.dbo.usp.MyTable.GetAllNewStuff.sql

응용 프로그램 및 버전을 고려한 버전 테이블을 사용하면 응용 프로그램은 주간 프로덕션 백업을 복원하고 현재 버전 이후 데이터베이스에 필요한 모든 스크립트를 실행합니다. .net을 사용함으로써 우리는 이것을 트랜잭션으로 쉽게 패키징 할 수 있었고 실패한 것이 있으면 롤백하고 이메일을 보낼 것이므로 릴리스에 잘못된 스크립트가 있음을 알았습니다.

따라서 모든 개발자는 소스 제어에서이 기능을 유지해야합니다. 따라서 조정 된 릴리스에서는 데이터베이스에 대해 실행하려는 모든 스크립트가 성공적으로 실행됩니다.

이것은 아마도 당신이 찾고있는 것보다 더 많은 정보 일 것이지만, 그것은 우리에게 매우 잘 작동했으며 구조가 주어지면 모든 개발자를 쉽게 참여시킬 수있었습니다.

릴리스 날짜가 다가 오면 운영 팀은 릴리스 노트를 따르고 소스 제어에서 스크립트를 선택하고 야간 빌드 프로세스 중에 사용한 .net 애플리케이션을 사용하여 데이터베이스에 대해 패키지를 실행하여 트랜잭션에서 스크립트를 자동으로 패키지합니다. 무언가 실패하면 자동으로 롤백되고 데이터베이스에 영향을 미치지 않습니다.

2
Dean Poulin

위의 Robert Paulson과 유사하게, 우리 조직은 데이터베이스를 소스 제어하에 유지합니다. 그러나 차이점은 우리가 가지고있는 스크립트의 수를 제한하려고한다는 것입니다.

새로운 프로젝트에는 정해진 절차가 있습니다. 버전 1의 스키마 생성 스크립트, 저장된 proc 생성 스크립트 및 초기 데이터로드 생성 스크립트가 있습니다. 모든 procs는 하나의 거대한 파일로 유지됩니다. 엔터프라이즈 라이브러리를 사용하는 경우 로깅을위한 작성 스크립트 사본이 포함됩니다. ASP.NET 응용 프로그램 프레임 워크 (인증, 개인 설정 등)를 사용하는 ASP.NET 프로젝트 인 경우 해당 스크립트도 포함합니다. (우리는 Microsoft의 도구에서 생성 한 다음 다른 사이트에서 복제 가능한 방식으로 작동 할 때까지 조정했습니다.

우리는 매직 CTRL + F를 사용하여 원하는 proc을 찾습니다. :) (SQL Management Studio에 VS와 같은 코드 탐색 기능이 있으면 좋겠습니다. Sigh!)

이후 버전의 경우 일반적으로 upgradeSchema, upgradeProc 및/또는 updateDate 스크립트가 있습니다. 스키마 업데이트의 경우 가능한 한 많은 테이블을 변경하여 필요에 따라 새 테이블을 만듭니다. proc 업데이트를 위해 DROP 및 CREATE를 수행합니다.

이 접근 방식으로 하나의 주름이 나타납니다. 데이터베이스를 생성하기 쉽고 현재 DB 버전에서 새로운 데이터베이스를 쉽게 만들 수 있습니다. 그러나 DB/스키마/프로세스 변경 사항에 액세스하는 데 사용 된 코드와 완전히 동기화되도록 DAL 생성 (현재는 일반적으로 SubSonic에서 수행)을주의해야합니다. 그러나 빌드 경로에는 SubSonic DAL을 생성하는 배치 파일이 있으므로 DAL 코드를 체크 아웃하고 해당 배치 파일을 다시 실행 한 다음 언제든지 다시 확인하는 것이 SOP)입니다. 스키마 및/또는 프로세스 변경 (물론 소스 빌드를 트리거하여 공유 DLL을 적절한 DLL로 업데이트 함)

2
John Rudy

우리 회사에서는 개별 코드 파일과 마찬가지로 소스 제어의 모든 데이터베이스 항목을 개별 스크립트로 저장하는 경향이 있습니다. 모든 업데이트는 먼저 데이터베이스에서 수행 된 다음 소스 코드 저장소로 마이그레이션되므로 변경 히스토리가 유지됩니다.
두 번째 단계로 모든 데이터베이스 변경 사항이 통합 데이터베이스로 마이그레이션됩니다. 이 통합 데이터베이스는 프로덕션 데이터베이스가 사후 배포와 같은 모습을 정확하게 나타냅니다. 또한 현재 생산 상태 (또는 마지막 배포)를 나타내는 QA 데이터베이스도 있습니다. 통합 데이터베이스에서 모든 변경이 이루어지면 스키마 차이 도구 (Red Gate의 SQL Server 용 SQL Diff)를 사용하여 한 데이터베이스에서 다른 데이터베이스로 모든 변경 사항을 마이그레이션하는 스크립트를 생성합니다.
이 기능은 설치 프로그램과 쉽게 통합 할 수있는 단일 스크립트를 생성하므로 상당히 효과적입니다. 우리가 종종 가장 큰 문제는 개발자가 변경 사항을 통합으로 마이그레이션하는 것을 잊어 버리는 것입니다.

1
Mitch

저장 프로시 저는 표준 if 존재하는 drop/create 문과 함께 sp 당 1 개의 파일을받습니다. 뷰와 함수는 자체 파일을 가져 오기 때문에 버전을 쉽게 지정하고 재사용 할 수 있습니다.

스키마는 모두 처음부터 시작하는 스크립트이므로 버전을 변경합니다.

이 모든 것은 다음과 같은 폴더 구조로 TFS (@ work 또는 VisualSVN Server @ home for personal stuff)에 연결된 Visual Studio 데이터베이스 프로젝트에 저장됩니다.
-프로젝트
-기능
-스키마
-저장 프로 시저
-- 견해

1
knight0323

우리는 현재 프로젝트에서 대체 접근법을 사용하고 있습니다. 소스 제어하에 db를 얻지 않고 대신 데이터베이스 diff 도구를 사용하여 각 릴리스에 도달 할 때 변경 사항을 스크립팅했습니다.
지금까지 매우 잘 작동하고 있습니다.

0
Rikalous

저장 프로 시저를 소스 제어로 유지합니다.

0
Darren Kopp

애플리케이션과 관련된 모든 것을 SCM에 저장합니다. DB 스크립트는 일반적으로 자체 프로젝트에 저장되지만 디자인, 구현, 테스트, 커밋과 같은 다른 코드와 같이 취급됩니다.

0
Chris Hall

모든 것 (객체 생성 등)을 스크립팅하고 해당 스크립트를 소스 제어에 저장하십시오. 변경은 어떻게 이루어 집니까? 작업 수행 방식에 대한 표준 관행의 일부입니다. 테이블을 추가해야합니까? CREATE TABLE 스크립트를 작성하십시오. sproc를 업데이트 하시겠습니까? 저장 프로 시저 스크립트를 편집하십시오.

객체 당 하나의 스크립트를 선호합니다.

0
ahockley

Procs의 경우 스크립트 래퍼가있는 procs를 일반 파일에 쓰고 해당 파일의 변경 사항을 적용하십시오. 올바르게 적용되면 해당 파일을 체크인 할 수 있으며 해당 파일에서도 해당 파일을 재생할 수 있습니다.

스키마 변경의 경우 스크립트를 체크인하여 점진적으로 변경해야합니다. 스크립트를 작성하고 적용한 후 체크인하십시오. 그런 다음 프로세스를 빌드하여 각 스키마 스크립트를 자동으로 연속 적용 할 수 있습니다.

0
John Flinchbaugh

저장 프로 시저를 소스 제어로 유지합니다. 우리 (또는 적어도 나는) 가하는 방법은 프로젝트에 폴더를 추가하고 각 SP 파일을 추가하고 수동으로 복사하여 코드를 붙여 넣는 것입니다. , 수동으로 파일을 소스 컨트롤로 변경해야합니다.

사람들이이 작업을 자동으로 수행 할 수 있는지 알고 싶습니다.

0
Rik