답변:
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
);
업그레이드 스크립트가 실행될 때마다 새 버전에 해당하는 새 항목을 가져옵니다.
이를 통해 어떤 버전의 데이터베이스 스키마가 있는지 쉽게 확인할 수 있으며 데이터베이스 업그레이드 스크립트가 한 번만 실행됩니다. 다시 말하지만 이들은 데이터베이스 덤프 가 아닙니다 . 오히려 각 스크립트는 한 버전에서 다음 버전으로 이동하는 데 필요한 변경 사항을 나타냅니다 . "업그레이드"하기 위해 프로덕션 데이터베이스에 적용하는 스크립트입니다.
경고 : 자동화 된 테스트는 스키마가 정확하지만 비어있는 데이터베이스에 대해 실행되므로이 조언은 사용자 요구에 완벽하게 맞지 않습니다.
Red Gate의 SQL Compare 제품을 사용하면 객체 수준 비교를 수행하고 그로부터 변경 스크립트를 생성 할 수있을뿐만 아니라 데이터베이스 객체를 하나의 [objectname] .sql 작성을 사용하여 객체 유형별로 구성된 폴더 계층 구조로 내보낼 수도 있습니다. 이 디렉토리의 오브젝트 당 스크립트. 객체 유형 계층 구조는 다음과 같습니다.
\ 기능
\ 보안
\ 보안 \ 역할
\ 보안 \ 스키마
\ 보안 \ 사용자
\ 저장 프로 시저
\ 테이블
변경 후 스크립트를 동일한 루트 디렉토리에 덤프하면이를 사용하여 SVN 저장소를 업데이트하고 각 오브젝트의 실행 히스토리를 개별적으로 유지할 수 있습니다.
이것은 개발을 둘러싼 "어려운 문제"중 하나입니다. 내가 아는 한 완벽한 솔루션은 없습니다.
데이터가 아닌 데이터베이스 구조 만 저장해야하는 경우 데이터베이스를 SQL 쿼리로 내보낼 수 있습니다. (Enterprise Manager : 데이터베이스-> SQL 스크립트 생성을 마우스 오른쪽 단추로 클릭하십시오. 옵션 탭에서 "개체 당 하나의 파일 작성"을 설정하는 것이 좋습니다.) 그런 다음이 텍스트 파일을 svn에 커밋하고 svn의 diff 및 logging 기능을 사용할 수 있습니다.
나는 이것을 몇 가지 매개 변수를 취하고 데이터베이스를 설정하는 배치 스크립트와 함께 묶었습니다. 또한 사용자 유형 및 관리자와 같은 기본 데이터를 입력하는 추가 쿼리를 추가했습니다. (이에 대한 자세한 정보를 원하면 뭔가를 게시하면 스크립트를 액세스 가능한 곳에 둘 수 있습니다)
모든 데이터를 유지해야하는 경우 데이터베이스 백업을 유지 하고 비교를 수행하기 위해 Redgate ( http://www.red-gate.com/ ) 제품을 사용하는 것이 좋습니다 . 그들은 싸게 오지 않지만 모든 페니의 가치가 있습니다.
먼저, 올바른 버전 관리 시스템을 선택해야합니다.
중앙 집중식 버전 제어 시스템-사용자가 파일 작업 전후에 체크 아웃 / 체크인하고 파일이 단일 중앙 서버에 유지되는 표준 시스템
분산 버전 제어 시스템-리포지토리가 복제되고 각 복제본이 실제로 리포지토리의 전체 백업이므로 시스템에 충돌이 발생하면 복제 된 리포지토리를 사용하여 복원 할 수 있습니다. 모든 버전 제어 시스템의 핵심 인 저장소를 설정해야합니다.이 모든 내용은 다음 기사에서 설명합니다. http://solutioncenter.apexsql.com/sql-server-source-control-part-i-understanding -source-control-basics /
리포지토리를 설정 한 후 중앙 버전 제어 시스템의 경우 작업 폴더 인 경우이 기사를 읽을 수 있습니다 . 다음을 사용하여 개발 환경에서 소스 제어를 설정하는 방법을 보여줍니다.
MSSCCI 공급자를 통한 SQL Server Management Studio
Visual Studio 및 SQL Server 데이터 도구
Red Gate 에서는 SQL 비교 기술을 사용하여 데이터베이스를 TFS 또는 SVN 저장소와 연결 하는 도구 인 SQL Source Control을 제공 합니다. 이 도구는 SSMS에 통합되어 있으며 이제 개체를 커밋 할 수 있다는 점을 제외하고 정상적으로 작업 할 수 있습니다.
마이그레이션 기반 접근 방식 (자동 배포에 더 적합)을 위해 Visual Studio 프로젝트로 증분 스크립트 집합을 만들고 관리하는 SQL Change Automation (이전의 ReadyRoll)을 제공합니다.
SQL 소스 제어에서 정적 데이터 테이블을 지정할 수 있습니다. 이들은 소스 제어에 INSERT 문으로 저장됩니다.
테스트 데이터에 대해 이야기하는 경우 도구를 사용하거나 정의한 배포 후 스크립트를 통해 테스트 데이터를 생성하거나 프로덕션 백업을 개발 환경으로 간단히 복원하는 것이 좋습니다.
Liquibase ( http://www.liquibase.org/ ) 를보고 싶을 수도 있습니다 . 도구 자체를 사용하지 않더라도 데이터베이스 변경 관리 또는 리팩토링 개념을 잘 처리합니다.
RedGate 도구를 추천 한 모든 사용자에게 +1, 추가 권장 사항 및 경고가 있습니다.
SqlCompare에는 문서화 된 API도 있습니다. 예를 들어, 소스 제어 스크립트 폴더를 체크인시 CI 통합 테스트 데이터베이스와 동기화하는 콘솔 앱을 작성하여 누군가가 스크립트 폴더에서 스키마 변경을 체크인 할 때 일치하는 응용 프로그램 코드 변경과 함께 자동으로 배포됩니다. 이를 통해 로컬 DB의 변경 사항을 공유 개발 DB로 전파하는 것을 잊어 버린 개발자와의 격차를 좁힐 수 있습니다 (우리 중 절반 정도 :)
스크립트 솔루션이나 그 밖의 방법으로 RedGate 도구가 충분히 매끄 럽기 때문에 추상화의 기본이되는 SQL 현실을 쉽게 잊을 수 있습니다. 테이블의 모든 열 이름을 바꾸면 SqlCompare는 이전 열을 새 열에 매핑 할 수 없으며 테이블의 모든 데이터를 삭제합니다. 경고가 발생하지만 사람들이 그 과거를 클릭하는 것을 보았습니다. 여기에는 일반적으로 DB 버전 관리 및 업그레이드 만 자동화 할 수 있다고 생각할 가치가 있습니다. 추상화는 매우 누수가 있습니다.
DBGhost 를 사용 하여 SQL 데이터베이스를 관리합니다. 그런 다음 버전 제어에서 새 데이터베이스를 작성하기 위해 스크립트를 배치하면 새 데이터베이스를 작성하거나 기존 데이터베이스를 버전 제어의 스키마로 업그레이드합니다. 이렇게하면 변경 스크립트 생성에 대해 걱정할 필요가 없습니다 (예를 들어 열의 데이터 유형을 변경하고 데이터를 변환해야하는 경우에도 여전히 그렇게 할 수는 있지만).
데이터베이스를 하나의 데이터베이스로 업그레이드 할 수 있도록 데이터베이스 스크립트를 변경 스크립트를 사용하여 버전 제어에 저장하는 것이 좋습니다. 또한 모든 변경 스크립트를 적용하지 않고 전체 데이터베이스를 작성할 수 있도록 다른 버전의 스키마를 저장하려고 할 수 있습니다. 수동 작업을 수행 할 필요가 없도록 스크립트 처리를 자동화해야합니다.
모든 개발자를 위해 별도의 데이터베이스를 보유하고 공유 데이터베이스를 사용하지 않는 것이 중요하다고 생각합니다. 그렇게하면 개발자는 다른 개발자와 독립적으로 테스트 사례 및 개발 단계를 만들 수 있습니다.
자동화 도구에는 데이터베이스 메타 데이터를 처리 할 수있는 수단이 있어야합니다. 데이터베이스 메타 데이터는 어떤 데이터베이스가 어떤 개발 상태에 있으며 어떤 테이블에 버전 제어 가능 데이터 등이 있는지 알려줍니다.
대상 환경이나 제약 조건에 대한 구체적인 언급은 없으므로 이것이 완전히 적용 가능한 것은 아니지만 진화하는 DB 스키마를 효과적으로 추적하는 방법을 찾고 있는데 사용의 아이디어에 불리하지 않은 경우 루비, ActiveRecord의 마이그레이션은 골목길에 있습니다.
마이그레이션은 Ruby DSL을 사용하여 프로그래밍 방식으로 데이터베이스 변환을 정의합니다. 각 변환을 적용하거나 (일반적으로) 롤백 할 수 있으므로 특정 시점에 다른 버전의 DB 스키마로 이동할 수 있습니다. 이러한 변환을 정의하는 파일은 다른 소스 코드와 마찬가지로 버전 제어로 확인할 수 있습니다.
마이그레이션은 ActiveRecord 의 일부이기 때문에 일반적으로 풀 스택 Rails 앱에서 사용됩니다. 그러나 최소한의 노력으로 Rails와 독립적으로 ActiveRecord를 사용할 수 있습니다. Rails 외부에서 AR 마이그레이션을 사용하는 방법에 대한 자세한 내용은 여기 를 참조 하십시오 .
모든 데이터베이스는 소스 코드로 제어되어야합니다. 부족한 것은 모든 데이터베이스 개체와 "구성 데이터"를 파일로 자동 스크립팅하여 모든 소스 제어 시스템에 추가 할 수있는 도구입니다. SQL Server를 사용하는 경우, 내 솔루션은 여기에 있습니다 : http://dbsourcetools.codeplex.com/ . 즐기세요 나단
간단 해.
기본 프로젝트가 준비되면 전체 데이터베이스 스크립트를 작성해야합니다. 이 스크립트는 SVN에 커밋됩니다. 첫 번째 버전입니다.
그런 다음 모든 개발자가 변경 스크립트 (ALTER ..., 새 테이블, sproc 등)를 만듭니다.
현재 버전이 필요하면 모든 새로운 변경 스크립트를 실행해야합니다.
앱이 프로덕션으로 출시되면 1로 돌아갑니다 (물론 연속 버전 임).
Nant는 이러한 변경 스크립트를 실행하는 데 도움을 줄 것입니다. :)
그리고 기억하십시오. 훈련이있을 때 모든 것이 잘 작동합니다. 데이터베이스 변경이 커밋 될 때마다 코드의 해당 함수도 커밋됩니다.
작은 데이터베이스가 있고 전체 버전을 관리하려는 경우이 배치 스크립트 가 도움 이 될 수 있습니다. MSSQL 데이터베이스 MDF 파일을 분리하고 압축하여 Subversion에 체크인합니다.
대부분 스키마의 버전을 변경하고 소량의 참조 데이터 만있는 경우 SubSonic Migration 을 사용 하여 처리 할 수 있습니다 . 특정 버전으로 쉽게 마이그레이션 할 수 있다는 이점이 있습니다.
소스 코드 제어 시스템으로의 덤프를 조금 더 빠르게하기 위해 sysobjects의 버전 정보를 사용하여 지난 시간 이후 변경된 오브젝트를 확인할 수 있습니다.
설정 : 마지막으로 확인한 시점부터 (첫 번째 실행시 비어 있음) 버전 정보를 유지하기 위해 점진적으로 확인할 테이블을 각 데이터베이스에 작성하십시오. 전체 데이터 구조를 다시 스캔하려면이 테이블을 지우십시오.
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
우리의 앱은 여러 RDBMS에서 작동해야하기 때문에 스키마 정의를 데이터베이스 중립적 토크 형식 (XML)을 사용하여 버전 제어에 저장합니다 . 또한 데이터베이스의 참조 데이터를 다음과 같이 XML 형식으로 버전 제어합니다 (여기서 "관계"는 참조 테이블 중 하나임).
<Relationship RelationshipID="1" InternalName="Manager"/>
<Relationship RelationshipID="2" InternalName="Delegate"/>
etc.
그런 다음 자체 개발 도구를 사용하여 데이터베이스 버전 X에서 버전 X + 1로 이동하는 데 필요한 스키마 업그레이드 및 참조 데이터 업그레이드 스크립트를 생성합니다.
x64 플랫폼으로 마이그레이션 한 후 이전 버전으로 마이그레이션하여 SQL 데이터베이스 버전을 변경해야했습니다. 우리는 SQLDMO를 사용하여 모든 SQL 객체를 폴더에 매핑하는 C # 응용 프로그램을 작성했습니다.
뿌리 서버 이름 데이터베이스 이름 스키마 객체 데이터베이스 트리거 * .ddltrigger.sql 기능 ..function.sql 보안 역할 응용 프로그램 역할 .approle.sql 데이터베이스 역할 .role.sql 스키마 * .schema.sql 사용자 .user.sql 저장 전문 카탈로그 * .fulltext.sql 저장 프로 시저 ..proc.sql 동의어 * .synonym.sql 테이블 ..table.sql 제약 ... chkconst.sql ... defconst.sql 인덱스 ... index.sql 열쇠 ... fkey.sql ... pkey.sql ... ukey.sql 트리거 ... trigger.sql 종류 사용자 정의 데이터 유형 ..uddt.sql XML 스키마 컬렉션 * ..xmlschema.sql 견해 ..view.sql 인덱스 ... index.sql 트리거 ... trigger.sql
그런 다음 응용 프로그램은 새로 작성된 버전을 SVN에 저장된 버전과 비교하고 차이가 있으면 SVN을 업데이트합니다. 우리는 SQL을 많이 변경하지 않았기 때문에 밤새 한 번 프로세스를 실행하는 것으로 충분하다고 판단했습니다. 이를 통해 관심있는 모든 객체에 대한 변경 사항을 추적하고 심각한 문제가 발생할 경우 전체 스키마를 재구성 할 수 있습니다.
나는이 응용 프로그램을 얼마 전에 작성 했는데 http://sqlschemasourcectrl.codeplex.com/ 은 원하는만큼 MSFT SQL DB를 스캔하고 자동으로 객체 (테이블, 뷰, 프로세서, 함수, SQL 설정)를 SVN에 덤프합니다. 매력처럼 작동합니다. 나는 Unfuddle과 함께 사용합니다 (체크 인에 대한 알림을받을 수 있습니다)
방금 Team Foundation Server를 사용하기 시작했습니다. 데이터베이스의 크기가 중간 크기 인 경우 Visual Studio에는 기본 제공 비교, 데이터 비교, 데이터베이스 리팩토링 도구, 데이터베이스 테스트 프레임 워크 및 데이터 생성 도구와의 훌륭한 프로젝트 통합 기능이 있습니다.
그러나이 모델은 규모가 크거나 타사 데이터베이스 (객체를 암호화하는)에 적합하지 않습니다. 우리가 한 일은 사용자 정의 된 객체 만 저장하는 것입니다. Visual Studio / Team Foundation 서버는 그 점에서 매우 효과적입니다.
나는 ESV 답변에 동의하며 정확한 이유로 데이터베이스 업데이트를 아주 간단한 파일로 유지 관리하기 위해 잠시 프로젝트를 시작한 다음 긴 소스 코드를 유지할 수 있습니다. UAT 및 프로덕션뿐만 아니라 개발자에게도 쉽게 업데이트 할 수 있습니다. 이 도구는 Sql Server 및 MySql에서만 작동합니다.
일부 프로젝트 기능 :
코드는 Google 코드에서 호스팅됩니다. 자세한 내용은 Google 코드를 확인하십시오
또한 데이터베이스 확장 속성 계열을 통해 저장된 데이터베이스 버전을 사용하고 있습니다. 내 응용 프로그램에는 각 버전 단계마다 스크립트가 있습니다 (예 : 1.1에서 1.2로 이동). 배포되면 현재 버전을보고 마지막 앱 버전에 도달 할 때까지 스크립트를 하나씩 실행합니다. 간단한 '최종'버전을 가진 스크립트는 없으며, 깨끗한 DB에 배포하더라도 일련의 업그레이드 단계를 통해 배포합니다.
이제 내가 추가하고 싶은 것은 이틀 전에 MS 캠퍼스에서 새롭고 다가오는 VS DB 에디션에 대한 프레젠테이션을 보았습니다. 프레젠테이션은이 주제에 특별히 초점을 맞추었고 물에서 날아갔습니다. 새로운 기능은 배포 스키마를 정의 된 스키마와 비교하고 델타 ALTER 및 소스 코드 통합과의 통합을 수행하는 런타임 델타 엔진 인 T-SQL 스크립트 (CREATE)에 스키마 정의를 유지하는 데 중점을두고 있습니다. 자동화 된 빌드 드롭을위한 MSBUILD 연속 통합을 포함합니다. 이 드롭에는 배포 사이트로 가져갈 수있는 새로운 파일 형식 인 .dbschema 파일이 포함되며 명령 줄 도구는 실제 '델타'를 수행하고 배포를 실행할 수 있습니다. 이 주제에 대한 VSDE 다운로드 링크가 포함 된 블로그 항목이 있습니다.http://rusanu.com/2009/05/15/version-control-and-your-database/
매우 오래된 질문이지만 많은 사람들이 지금도이 문제를 해결하려고합니다. Visual Studio 데이터베이스 프로젝트에 대해 조사하면됩니다. 이것이 없으면 데이터베이스 개발이 매우 어려워 보입니다. 코드 구성에서 배포, 버전 관리에 이르기까지 모든 것을 단순화합니다.
내 경험상 솔루션은 두 가지입니다.
개발 중에 여러 개발자가 수행 한 개발 데이터베이스의 변경 사항을 처리해야합니다.
고객 사이트에서 데이터베이스 업그레이드를 처리해야합니다.
# 1을 처리하려면 강력한 데이터베이스 diff / merge 도구가 필요합니다. 최상의 도구는 가능한 한 자동 병합을 수행하면서 처리되지 않은 충돌을 수동으로 해결할 수 있어야합니다.
완벽한 툴은 BASE 데이터베이스와 관련하여 THEIRS 데이터베이스 및 MINE 데이터베이스에서 변경된 사항을 고려한 3 방향 병합 알고리즘을 사용하여 병합 작업을 처리해야합니다.
SQLite 데이터베이스에 대한 수동 병합 지원을 제공하는 상용 도구를 작성했으며 현재 SQLite에 대한 3 방향 병합 알고리즘에 대한 지원을 추가하고 있습니다. http://www.sqlitecompare.com 에서 확인하십시오 .
# 2를 처리하려면 업그레이드 프레임 워크가 필요합니다.
기본 아이디어는 기존 SQL 스키마에서 최신 SQL 스키마로 업그레이드하는 방법을 알고 있으며 기존 DB 설치마다 업그레이드 경로를 구축 할 수있는 자동 업그레이드 프레임 워크를 개발하는 것입니다.
http://www.codeproject.com/KB/database/sqlite_upgrade.aspx 의 주제에 대한 내 기사를 확인하십시오 .내가 말하는 것에 대한 일반적인 아이디어를 얻으려면 .
행운을 빕니다
리론 레비
DBGhost http://www.innovartis.co.uk/를 확인 하십시오 . 나는 2 년 동안 자동화 된 방식으로 사용 해 왔으며 훌륭하게 작동합니다. 데이터베이스를 제외하고 DB 빌드는 Java 또는 C 빌드와 매우 유사합니다. 무슨 말인지 알 잖아
데이터베이스의 버전 관리 시스템을 개선하기 위해 비교 도구를 사용하는 것이 좋습니다. 좋은 대안은 xSQL Schema Compare 및 xSQL Data Compare 입니다.
이제 버전 제어에 데이터베이스 스키마 만있는 것이 목표 인 경우 xSQL 스키마 비교를 사용하여 스키마의 xSQL 스냅 샷을 생성하고 이러한 파일을 버전 제어에 추가 할 수 있습니다. 특정 버전으로 되돌 리거나 업데이트하려면 현재 버전의 데이터베이스를 대상 버전의 스냅 샷과 비교하십시오.
아아, 데이터를 버전 제어하에두고 싶다면 xSQL Data Compare를 사용하여 데이터베이스에 대한 변경 스크립트를 생성하고 버전 제어에 .sql 파일을 추가 할 수 있습니다. 그런 다음이 스크립트를 실행하여 원하는 버전으로 되돌 리거나 업데이트 할 수 있습니다. '복귀'기능의 경우 실행시 버전 3을 버전 2와 동일하게 만들고 '업데이트'기능의 경우 변경 스크립트를 생성해야하는 변경 스크립트를 생성해야합니다.
마지막으로, 기본적인 배치 프로그래밍 기술을 사용하면 명령 줄 버전의 xSQL Schema Compare 및 xSQL Data Compare를 사용하여 전체 프로세스를 자동화 할 수 있습니다.
면책 조항 : 저는 xSQL에 소속되어 있습니다.