SQL Server 데이터베이스 버전 제어 방법
데이터베이스를 버전 관리 하에 두고 싶다.
적어도 데이터(알람에서 언급했듯이, 사용자 유형과 관리자)는 항상 가지고 있어야 합니다.또한 성능 측정을 위해 생성된 테스트 데이터를 대량으로 수집해야 하는 경우도 종종 있습니다.
데이터베이스에 버전 제어를 적용하려면 어떻게 해야 합니까?
Martin Fowler는 http://martinfowler.com/articles/evodb.html이라는 주제에 대해 제가 가장 좋아하는 기사를 썼습니다.운영 데이터베이스를 쉽게 업그레이드할 수 있는 방법을 원하기 때문에 alumb 등의 제안대로 스키마 덤프를 버전 관리 하에 두지 않기로 선택했습니다.
단일 프로덕션 데이터베이스 인스턴스를 사용하는 웹 애플리케이션의 경우 다음 두 가지 기술을 사용합니다.
데이터베이스 업그레이드스크립트
버전 N에서N+1로 스키마를 이동하는데 필요한 DDL을 포함하는 시퀀스 데이터베이스 업그레이드스크립트입니다(이러한 스크립트는 버전 제어 시스템에 포함됩니다)._version_history_테이블 같은 것
create table VersionHistory (
Version int primary key,
UpgradeStart datetime not null,
UpgradeEnd datetime
);
는 업그레이드스크립트가 실행될 때마다 새 버전을 지원하는 새 엔트리를 가져옵니다.
이렇게 하면 데이터베이스 스키마의 버전을 쉽게 확인할 수 있고 데이터베이스 업그레이드 스크립트가 한 번만 실행됩니다.이것도 데이터베이스 덤프가 아닙니다.각 스크립트는 버전 간에 이동하는 데 필요한 변경을 나타냅니다.이러한 스크립트는 프로덕션 데이터베이스를 "업그레이드"하기 위해 적용할 스크립트입니다.
개발자 샌드박스 동기화
- 프로덕션 데이터베이스를 백업, 삭제 및 축소하는 스크립트입니다.프로덕션 DB로 업그레이드할 때마다 이 작업을 실행하십시오.
- 개발자의 워크스테이션에서 백업을 복원(필요한 경우 수정)하기 위한 스크립트입니다.각 개발자는 프로덕션 DB로 업그레이드한 후 이 스크립트를 실행합니다.
경고:자동 테스트는 스키마가 올바르지만 빈 데이터베이스에 대해 실행되므로 이 조언은 사용자의 요구에 완벽하게 부합하지 않습니다.
이 기능을 제공하는 상용 제품은 다음과 같습니다.
RedGate 사용자의 경우
Red Gate의 SQL Compare 제품을 사용하는 경우 객체 수준의 비교를 수행하고 변경 스크립트를 생성할 수 있습니다.또한 하나의 [objectname]을 사용하여 데이터베이스 개체를 개체 유형별로 구성된 폴더 계층으로 내보낼 수도 있습니다.이러한 디렉토리의 개체당 sql 생성 스크립트.오브젝트 타입의 계층은 다음과 같습니다.
\ 능능
\ 안안
\\\
\\\Schemas\
사용자\\
\Stored Procedure(저장 프로시저)
\ 이 \
변경 후 스크립트를 같은 루트 디렉토리에 덤프하면 이를 사용하여 SVN repo를 갱신하고 각 객체의 실행 이력을 개별적으로 유지할 수 있습니다.
이것은 개발을 둘러싼 「어려운 문제」의 하나입니다.내가 아는 한 완벽한 해결책은 없다.
데이터가 아닌 데이터베이스 구조만 저장해야 하는 경우 데이터베이스를 SQL 쿼리로 내보낼 수 있습니다.(Enterprise Manager: 데이터베이스 우클릭 -> SQL 스크립트 생성).Options 탭에서 "Create one file per object"를 설정하는 것을 권장합니다).이 텍스트파일을 svn으로 커밋하여 svn의 diff 및 logging 기능을 사용할 수 있습니다.
몇 가지 파라미터를 사용하여 데이터베이스를 셋업하는 배치 스크립트와 함께 이 스크립트가 연결되어 있습니다.또한 사용자 유형 및 관리자 사용자 등의 기본 데이터를 입력하는 쿼리를 추가했습니다(자세한 내용은 스크립트를 접근 가능한 곳에 게시하십시오).
모든 데이터를 보관해야 하는 경우에는 데이터베이스를 백업하고 Redgate(http://www.red-gate.com/) 제품)를 사용하여 비교할 것을 권장합니다.싸지는 않지만 한 푼의 값어치도 있다.
먼저 자신에게 적합한 버전 관리 시스템을 선택해야 합니다.
일원화된 버전 관리 시스템 - 사용자가 파일 작업 전/후에 체크아웃/체크인하여 파일을 하나의 중앙 서버에 보관하는 표준 시스템
분산 버전 관리 시스템 - 저장소가 클로닝되고 각 클론이 실제로 저장소의 풀백업이기 때문에 서버가 크래쉬 했을 경우 클로닝된 저장소를 사용하여 복원하는 것이 가능합니다.고객의 요구에 맞는 시스템을 선택한 후,모든 버전 관리 시스템의 핵심인 저장소를 설정해야 합니다.이 모든 것에 대해서는, 다음의 기사를 참조해 주세요.http://solutioncenter.apexsql.com/sql-server-source-control-part-i-understanding-source-control-basics/
저장소를 설정한 후 중앙 버전 관리 시스템의 경우 작업 폴더인 경우 이 문서를 읽을 수 있습니다.다음 항목을 사용하여 개발 환경에서 소스 제어를 설정하는 방법을 보여 줍니다.
SQL Server Management Studio (MSCCI 프로바이더 경유)
Visual Studio 및 SQL Server 데이터 도구
- 서드파티 툴 ApexSQL 소스 컨트롤
RedGate 툴을 추천하는 모든 사용자에게 +1을 제공하고 추가 권장사항과 주의사항을 제공합니다.
Sql Compare에는 문서화된 API도 있습니다.예를 들어 체크인 시 소스 제어 스크립트 폴더를 CI 통합 테스트 데이터베이스와 동기화하는 콘솔 앱을 작성할 수 있습니다.따라서 스크립트 폴더에서 스키마 변경을 체크인하면 일치하는 애플리케이션 코드 변경과 함께 자동으로 전개됩니다.이를 통해 로컬 DB의 변경을 공유 개발 DB로 전파하는 것을 잊어버리는 개발자와의 격차를 좁힐 수 있습니다(우리 중 절반 정도가 :).
주의할 점은 스크립트 형식의 솔루션 등에서는 RedGate 툴이 충분히 원활하여 추상화의 기반이 되는 SQL 현실을 쉽게 잊어버릴 수 있다는 것입니다.테이블의 모든 열의 이름을 변경하면 SqlCompare에서는 이전 열을 새 열에 매핑할 수 없으며 테이블의 모든 데이터가 삭제됩니다.경고가 생성되겠지만 클릭하는 사람을 본 적이 있습니다.여기서 언급할 가치가 있는 일반적인 요점은 지금까지 DB 버전 관리 및 업그레이드만 자동화할 수 있다는 것입니다. 추상적인 개념은 매우 누출되어 있습니다.
VS 2010에서는 Database 프로젝트를 사용합니다.
- 데이터베이스 스크립트 아웃
- 스크립트를 변경하거나 db 서버에서 직접 변경
- [ Data ]> [ Schema Compare ]를 사용하여 동기화합니다.
완벽한 DB 버전 관리 솔루션을 만들고 DB 동기화를 용이하게 합니다.
데이터베이스 스크립트를 버전 제어에 저장하여 변경 스크립트를 사용하여 보유하고 있는 데이터베이스를 업그레이드할 수 있도록 하는 것이 좋습니다.또한 모든 변경 스크립트를 적용하지 않고도 전체 데이터베이스를 작성할 수 있도록 다른 버전의 스키마를 저장할 수도 있습니다.수동 작업을 하지 않아도 되도록 스크립트 처리를 자동화해야 합니다.
공유 데이터베이스를 사용하지 않고 개발자마다 별도의 데이터베이스를 갖는 것이 중요하다고 생각합니다.이를 통해 개발자는 다른 개발자와 독립적으로 테스트 사례와 개발 단계를 작성할 수 있습니다.
자동화 툴에는 데이터베이스 메타데이터를 처리하는 수단이 필요합니다.이 방법은 어떤 데이터베이스가 어떤 개발 상태에 있는지, 어떤 테이블이 버전 제어 가능한 데이터를 포함하고 있는지 등을 나타냅니다.
이행 솔루션을 검토할 수도 있습니다.이를 통해 C# 코드로 데이터베이스 스키마를 지정하고 MSBuild를 사용하여 데이터베이스 버전을 위아래로 롤다운할 수 있습니다.
현재 DBUP을 사용하고 있는데 잘 작동하고 있습니다.
타겟 환경이나 제약에 대해 구체적으로 언급하지 않았으므로, 이 내용이 완전히 해당되지는 않을 수 있습니다.그러나 진화하는 DB 스키마를 효과적으로 추적하고 Ruby를 사용하는 아이디어에 반대하지 않는 방법을 찾고 있다면 ActiveRecord의 마이그레이션이 가장 적합합니다.
마이그레이션은 Ruby DSL을 사용하여 데이터베이스 변환을 프로그램적으로 정의합니다. 각 변환을 적용하거나 (일반적으로) 롤백할 수 있으므로 특정 시점에 다른 버전의 DB 스키마로 이동할 수 있습니다.이러한 변환을 정의하는 파일은 다른 소스 코드와 마찬가지로 버전 제어에 체크인할 수 있습니다.
이행은 ActiveRecord의 일부이기 때문에 일반적으로 풀스택 Rails 앱에서 사용할 수 있습니다.단, ActiveRecord는 Rails에 의존하지 않고 최소한의 노력으로 사용할 수 있습니다.레일즈 외부에서 AR의 마이그레이션을 사용하는 방법에 대한 자세한 내용은 여기를 참조하십시오.
간단해요.
기본 프로젝트가 준비되면 전체 데이터베이스 스크립트를 생성해야 합니다.이 스크립트는 SVN에 커밋됩니다.첫 번째 버전입니다.
그 후 모든 개발자는 변경 스크립트(ALTER..., 새 테이블, sproc 등)를 작성합니다.
최신 버전이 필요한 경우 새 변경 스크립트를 모두 실행해야 합니다.
앱이 실가동되면 1로 돌아갑니다(그것은 물론 연속버전이 됩니다.
Nant는 이러한 변경 스크립트의 실행을 지원합니다.:)
그리고 기억하세요.규율이 있으면 모든 것이 잘 된다.데이터베이스 변경이 커밋될 때마다 코드 내의 해당 함수도 커밋됩니다.
당사의 앱은 여러 RDBMS에서 작동해야 하므로 데이터베이스 중립형 Torque 형식(XML)을 사용하여 스키마 정의를 버전 제어에 저장합니다.또한 다음과 같이 데이터베이스의 참조 데이터를 XML 형식으로 버전 관리합니다(여기서 "Relationship"은 참조 테이블 중 하나임).
<Relationship RelationshipID="1" InternalName="Manager"/>
<Relationship RelationshipID="2" InternalName="Delegate"/>
etc.
그런 다음 자체 개발한 도구를 사용하여 데이터베이스 버전 X에서 버전 X + 1로 이행하기 위해 필요한 스키마 업그레이드 및 참조 데이터 업그레이드 스크립트를 생성합니다.
소규모 데이터베이스를 사용하여 전체 버전을 작성하려는 경우 이 배치 스크립트가 도움이 될 수 있습니다.MSSQL 데이터베이스 MDF 파일을 Subversion으로 분리, 압축 및 체크인합니다.
스키마를 버전화하고 참조 데이터가 적은 경우 SubSonic Migrations를 사용하여 처리할 수 있습니다.이러한 이점은 특정 버전으로 쉽게 마이그레이션하거나 마이그레이션할 수 있다는 것입니다.
데이터베이스 스키마를 저장하지 않고 변경 사항을 데이터베이스에 저장합니다.스키마 변경 내용을 저장하여 데이터베이스의 모든 버전에 대한 변경 스크립트를 작성하여 고객의 데이터베이스에 적용합니다.저는 메인 어플리케이션과 함께 배포되는 데이터베이스 유틸리티 앱을 작성했습니다.이 앱은 스크립트를 읽고 어떤 업데이트를 적용해야 하는지 알 수 있습니다.또한 필요에 따라 보기 및 저장 프로시저를 새로 고칠 수 있는 충분한 스마트 기능을 갖추고 있습니다.
소스 코드 제어 시스템으로의 덤프를 조금 더 빠르게 만들려면 sysobjects의 버전 정보를 사용하여 이전부터 변경된 개체를 확인할 수 있습니다.
Setup: 마지막으로 체크했을 때의 버전 정보를 유지하기 위해 증분 체크할 각 데이터베이스에 테이블을 만듭니다(첫 번째 실행 시 비어 있음).전체 데이터 구조를 다시 검색하려면 이 테이블을 지우십시오.
IF ISNULL(OBJECT_ID('last_run_sysversions'), 0) <> 0 DROP TABLE last_run_sysversions
CREATE TABLE last_run_sysversions (
name varchar(128),
id int, base_schema_ver int,
schema_ver int,
type char(2)
)
일반 실행 모드:이 sql에서 결과를 가져와 원하는 sql 스크립트를 생성하여 원하는 소스 제어에 넣을 수 있습니다.
IF ISNULL(OBJECT_ID('tempdb.dbo.#tmp'), 0) <> 0 DROP TABLE #tmp
CREATE TABLE #tmp (
name varchar(128),
id int, base_schema_ver int,
schema_ver int,
type char(2)
)
SET NOCOUNT ON
-- Insert the values from the end of the last run into #tmp
INSERT #tmp (name, id, base_schema_ver, schema_ver, type)
SELECT name, id, base_schema_ver, schema_ver, type FROM last_run_sysversions
DELETE last_run_sysversions
INSERT last_run_sysversions (name, id, base_schema_ver, schema_ver, type)
SELECT name, id, base_schema_ver, schema_ver, type FROM sysobjects
-- This next bit lists all differences to scripts.
SET NOCOUNT OFF
--Renamed.
SELECT 'renamed' AS ChangeType, t.name, o.name AS extra_info, 1 AS Priority
FROM sysobjects o INNER JOIN #tmp t ON o.id = t.id
WHERE o.name <> t.name /*COLLATE*/
AND o.type IN ('TR', 'P' ,'U' ,'V')
UNION
--Changed (using alter)
SELECT 'changed' AS ChangeType, o.name /*COLLATE*/,
'altered' AS extra_info, 2 AS Priority
FROM sysobjects o INNER JOIN #tmp t ON o.id = t.id
WHERE (
o.base_schema_ver <> t.base_schema_ver
OR o.schema_ver <> t.schema_ver
)
AND o.type IN ('TR', 'P' ,'U' ,'V')
AND o.name NOT IN ( SELECT oi.name
FROM sysobjects oi INNER JOIN #tmp ti ON oi.id = ti.id
WHERE oi.name <> ti.name /*COLLATE*/
AND oi.type IN ('TR', 'P' ,'U' ,'V'))
UNION
--Changed (actually dropped and recreated [but not renamed])
SELECT 'changed' AS ChangeType, t.name, 'dropped' AS extra_info, 2 AS Priority
FROM #tmp t
WHERE t.name IN ( SELECT ti.name /*COLLATE*/ FROM #tmp ti
WHERE NOT EXISTS (SELECT * FROM sysobjects oi
WHERE oi.id = ti.id))
AND t.name IN ( SELECT oi.name /*COLLATE*/ FROM sysobjects oi
WHERE NOT EXISTS (SELECT * FROM #tmp ti
WHERE oi.id = ti.id)
AND oi.type IN ('TR', 'P' ,'U' ,'V'))
UNION
--Deleted
SELECT 'deleted' AS ChangeType, t.name, '' AS extra_info, 0 AS Priority
FROM #tmp t
WHERE NOT EXISTS (SELECT * FROM sysobjects o
WHERE o.id = t.id)
AND t.name NOT IN ( SELECT oi.name /*COLLATE*/ FROM sysobjects oi
WHERE NOT EXISTS (SELECT * FROM #tmp ti
WHERE oi.id = ti.id)
AND oi.type IN ('TR', 'P' ,'U' ,'V'))
UNION
--Added
SELECT 'added' AS ChangeType, o.name /*COLLATE*/, '' AS extra_info, 4 AS Priority
FROM sysobjects o
WHERE NOT EXISTS (SELECT * FROM #tmp t
WHERE o.id = t.id)
AND o.type IN ('TR', 'P' ,'U' ,'V')
AND o.name NOT IN ( SELECT ti.name /*COLLATE*/ FROM #tmp ti
WHERE NOT EXISTS (SELECT * FROM sysobjects oi
WHERE oi.id = ti.id))
ORDER BY Priority ASC
주의: 데이터베이스에서 비표준 데이터 정렬을 사용하는 경우 대체해야 합니다./* COLLATE */
대조와 사용할 수 .COLLATE Latin1_General_CI_AI
일반적인 솔루션은 필요에 따라 데이터베이스를 덤프하고 해당 파일을 백업하는 것입니다.
사용하시는 개발 플랫폼에 따라서는 오픈소스 플러그인을 사용할 수 있습니다.통상, 독자적인 코드를 굴리는 것은 매우 간단합니다.
주의: 데이터베이스 덤프를 버전 제어에 넣지 않고 백업할 수 있습니다.이 파일은 버전 관리에서 매우 빠르게 처리되어 소스 제어 시스템 전체의 속도가 느려질 수 있습니다(CVS의 공포 이야기를 떠올리고 있습니다).
이것은 매우 오래된 질문이지만, 많은 사람들이 지금도 이 문제를 해결하려고 하고 있다.Visual Studio Database Projects에 대한 조사만 하면 됩니다.이것이 없으면 데이터베이스 개발은 매우 미약해 보입니다.코드 구성부터 도입, 버전 관리까지 모든 것을 단순화합니다.
x64 플랫폼으로 이행한 후 이전 버전이 이행과 함께 고장난 후 SQL 데이터베이스를 버전업해야 했습니다.SQLDMO를 사용하여 모든 SQL 객체를 폴더에 매핑하는 C# 어플리케이션을 작성했습니다.
뿌리서버명데이터베이스명스키마 오브젝트데이터베이스 트리거*.ddltrigger.sql기능들..기능.sql보안.역할응용 프로그램 역할.approw.sql데이터베이스 역할.role.sql스키마*.discloss.sql사용자.user.sql보관소풀 텍스트 카탈로그*.풀텍스트.sql스토어드 프로시저..sql.sql동의어*.동의어.sql테이블..테이블.sql제약...chkconst.sql디콘스턴트sql인덱스...index.sql열쇠들....fkey.sql...pkey.sql...ukey.sql트리거...트리거.sql종류들사용자 정의 데이터 유형..udt.sqlXML 스키마 컬렉션*..xmlschema.sql표시..view.sql인덱스...index.sql트리거...트리거.sql
그런 다음 응용 프로그램은 새로 작성된 버전을 SVN에 저장된 버전과 비교하고 차이가 있을 경우 SVN을 업데이트합니다.SQL을 그렇게 많이 변경하지 않았기 때문에 하룻밤에 한 번 프로세스를 실행하는 것으로 충분하다고 판단했습니다.또한 중요한 모든 객체에 대한 변경을 추적할 수 있으며 심각한 문제가 발생한 경우에도 전체 스키마를 재구축할 수 있습니다.
ESV의 답변에 동의하기 때문에 저는 데이터베이스 업데이트를 매우 간단한 파일로 유지하기 위해 조금 전에 프로젝트를 시작했습니다.그러면 오랫동안 외부 소스 코드를 유지할 수 있습니다.UAT 및 프로덕션뿐만 아니라 개발자도 쉽게 업데이트할 수 있습니다.이 도구는 SQL Server 및 MySQL에서 작동합니다.
일부 프로젝트 기능:
- 스키마 변경을 허용합니다.
- 값 트리 채우기를 허용합니다.
- 에 대해 별도의 테스트 데이터 삽입을 허용합니다.UAT
- 롤백 옵션 허용(자동화되지 않음)
- SQL Server 및 MySQL 지원 유지
- 하나의 간단한 명령으로 기존 데이터베이스를 버전 관리로 Import할 수 있는 기능(SQL Server만 해당... MySQL에서 계속 작동)
자세한 내용은 코드를 확인하십시오.
데이터베이스 확장 속성 패밀리 프로시저를 통해 저장된 데이터베이스 버전도 사용하고 있습니다.응용 프로그램에는 버전 단계별로 스크립트가 있습니다(1.1에서 1.2로 이동).배포되면 현재 버전을 확인한 다음 마지막 앱 버전에 도달할 때까지 스크립트를 하나씩 실행합니다.스트레이트 '최종' 버전을 가진 스크립트는 없습니다. 클린 DB에 배포하는 경우에도 일련의 업그레이드 단계를 통해 배포합니다.
덧붙이고 싶은 것은 이틀 전에 MS 캠퍼스에서 새로운 VS DB 에디션에 대한 프레젠테이션을 봤다는 점입니다.프레젠테이션은 특히 이 주제에 초점을 맞추고 있어서 나는 당황했다.반드시 확인해야 합니다. 새로운 기능은 배포 스키마를 정의된 스키마와 비교하는 런타임 델타 엔진인 T-SQL 스크립트(CREATE)에 스키마 정의를 유지하는 데 중점을 두고 있으며, 자동 빌드 폐기를 위한 MSBUILD 연속 통합까지 델타 ALTER 및 소스 코드 통합을 수행합니다.드롭에는 새로운 파일 형식인 .dbschema 파일이 포함됩니다.이 파일은 배포 사이트로 가져올 수 있으며 명령줄 도구는 실제 '델타'를 수행하고 배포를 실행할 수 있습니다.이 토픽에 관한 블로그 엔트리에 VSDE 다운로드 링크가 있습니다.http://rusanu.com/2009/05/15/version-control-and-your-database/ 를 참조해 주세요.
얼마 전 DMO 및 VSS 객체를 사용하여 스크립트 형식의 DB 전체를 VSS로 가져오는 VB bas 모듈을 발견했습니다.VB 스크립트로 만들어서 여기에 올렸어요.VSS 콜을 간단하게 꺼내 DMO를 사용하여 모든 스크립트를 생성한 후 VBScript를 호출하여 체크인하는 배치파일에서 SVN을 호출할 수 있습니다.
제 경험상 해결책은 두 가지입니다.
개발 중에 여러 개발자가 수행한 개발 데이터베이스 변경 사항을 처리해야 합니다.
고객 사이트에서 데이터베이스 업그레이드를 처리해야 합니다.
#1을 처리하려면 강력한 데이터베이스 diff/merge 도구가 필요합니다.처리되지 않은 충돌을 수동으로 해결하면서 가능한 한 많은 자동 병합을 수행할 수 있는 최적의 도구가 필요합니다.
완벽한 도구는 BASE 데이터베이스에 대해 THESE 데이터베이스와 MINE 데이터베이스에서 이루어진 변경을 고려하는 3방향 병합 알고리즘을 사용하여 병합 작업을 처리해야 합니다.
SQLite 데이터베이스에 대한 수동 병합 지원을 제공하는 상용 도구를 작성했으며 현재 SQLite에 대한 3방향 병합 알고리즘 지원을 추가하고 있습니다.http://www.sqlitecompare.com에서 확인하세요.
#2를 처리하려면 업그레이드 프레임워크가 필요합니다.
기본 개념은 기존 SQL 스키마에서 새로운 SQL 스키마로 업그레이드하는 방법을 알고 모든 기존 DB 설치에 대한 업그레이드 경로를 구축할 수 있는 자동 업그레이드 프레임워크를 개발하는 것입니다.
http://www.codeproject.com/KB/database/sqlite_upgrade.aspx에서 이 주제에 대한 제 기사를 보고 제가 무슨 말을 하고 있는지 대략적으로 알아보시기 바랍니다.
행운을 빌어요
리론 리바이스
언급URL : https://stackoverflow.com/questions/173/how-to-do-version-control-for-sql-server-database
'programing' 카테고리의 다른 글
핵심 데이터:엔티티의 모든 인스턴스를 삭제하는 가장 빠른 방법 (0) | 2023.04.19 |
---|---|
DataReader를 목록으로 쉽게 변환하려면 어떻게 해야 합니까? (0) | 2023.04.19 |
WPF에서 UI(메인) 스레드에 안전하게 액세스 (0) | 2023.04.19 |
배시 템플릿:Bash를 사용하여 템플릿에서 구성 파일을 작성하는 방법 (0) | 2023.04.19 |
Bash 스크립트가 병렬로 제한된 수의 명령을 처리합니다. (0) | 2023.04.19 |