데이터베이스 구조 변경을위한 버전 관리 시스템이 있습니까?

나는 종종 다음과 같은 문제에 직면합니다.

데이터베이스에 새 테이블이나 열이 필요한 프로젝트의 일부 변경 작업을 수행합니다. 데이터베이스를 수정하고 작업을 계속합니다. 일반적으로 라이브 시스템에서 복제 할 수 있도록 변경 사항을 기록해 두는 것을 기억합니다. 그러나 나는 내가 무엇을 바꿨는지 항상 기억하지 못하고 그것을 적어 두는 것을 항상 기억하지 않는다.

그래서 라이브 시스템으로 밀어 NewColumnX붙이고, ugh 가 없다는 크고 명백한 오류가 발생합니다 .

이것이이 상황에 대한 모범 사례가 아닐 수도 있다는 사실과 상관없이 데이터베이스에 대한 버전 제어 시스템이 있습니까? 특정 데이터베이스 기술은 신경 쓰지 않습니다. 나는 그저 존재하는지 알고 싶다. MS SQL Server에서 작동한다면 훌륭합니다.

Ruby on Rails에는 마이그레이션 의 개념 이 있습니다. 데이터베이스를 변경하는 빠른 스크립트입니다.

db 버전을 높이는 규칙 (예 : 열 추가)과 버전을 다운 그레이드하는 규칙 (예 : 열 제거)이있는 마이그레이션 파일을 생성합니다. 각 마이그레이션에는 번호가 매겨지며 테이블은 현재 db 버전을 추적합니다.

를 마이그레이션 하려면 버전을 확인하고 필요한 스크립트를 적용하는 "db : migrate"라는 명령을 실행합니다. 비슷한 방법으로 아래로 마이그레이션 할 수 있습니다.

마이그레이션 스크립트 자체는 버전 제어 시스템에 보관됩니다. 데이터베이스를 변경할 때마다 새 스크립트를 체크인하고 모든 개발자가이를 적용하여 로컬 DB를 최신 버전으로 가져올 수 있습니다.

나는 데이터베이스를 만들기 위해 소스 파일을 사용한다는 점에서 약간 구식입니다. 실제로 두 개의 파일 (project-database.sql 및 project-updates.sql)이 있습니다. 첫 번째는 스키마 및 지속성 데이터 용이고 다른 하나는 수정 용입니다. 물론 둘 다 소스 제어하에 있습니다.

데이터베이스가 변경되면 먼저 project-database.sql의 기본 스키마를 업데이트 한 다음 관련 정보를 project-updates.sql에 복사합니다 (예 : ALTER TABLE 문). 그런 다음 업데이트를 개발 데이터베이스에 적용하고 테스트하고 잘 완료 될 때까지 반복 할 수 있습니다. 그런 다음 파일을 체크인하고 다시 테스트하고 프로덕션에 적용하십시오.

또한 일반적으로 db-Config에 다음과 같은 테이블이 있습니다.

SQL

CREATE TABLE Config
(
    cfg_tag VARCHAR(50),
    cfg_value VARCHAR(100)
);

INSERT INTO Config(cfg_tag, cfg_value) VALUES
( 'db_version', '$Revision: $'),
( 'db_revision', '$Revision: $');

그런 다음 업데이트 섹션에 다음을 추가합니다.

UPDATE Config SET cfg_value='$Revision: $' WHERE cfg_tag='db_revision';

db_version는 데이터베이스가 다시 때 변화 도착하고는 db_revision나에게 DB를 기준 떨어져 얼마나 멀리 표시를 제공합니다.

업데이트를 별도의 파일에 보관할 수 있지만 모두 함께 매시고 잘라 내기 및 붙여 넣기를 사용하여 관련 섹션을 추출하도록 선택했습니다. 좀 더 정리가 필요합니다. 즉, $ Revision 1.1 $에서 ':'을 제거하여 고정합니다.

MyBatis (이전의 iBatis)에는 명령 줄에서 사용할 수 있는 스키마 마이그레이션 도구가 있습니다. Java로 작성되었지만 모든 프로젝트에서 사용할 수 있습니다.

좋은 데이터베이스 변경 관리 관행을 달성하려면 몇 가지 주요 목표를 식별해야합니다. 따라서 MyBatis Schema Migration System (또는 줄여서 MyBatis Migrations)은 다음을 추구합니다.

• 신규 또는 기존 데이터베이스로 작업
• 소스 제어 시스템 (예 : Subversion) 활용
• 동시 개발자 또는 팀이 독립적으로 작업 할 수 있습니다.
• 충돌을 눈에 잘 띄고 쉽게 관리 할 수 ​​있습니다.
• 순방향 및 역방향 마이그레이션 허용 (각각 진화, 위임)
• 데이터베이스의 현재 상태를 쉽게 액세스하고 이해할 수 있도록합니다.
• 액세스 권한 또는 관료주의에도 불구하고 마이그레이션 가능
• 모든 방법론으로 작업
• 우수하고 일관된 관행을 장려합니다.

Redgate에는 SQL Source Control 이라는 제품이 있습니다. TFS, SVN, SourceGear Vault, Vault Pro, Mercurial, Perforce 및 Git과 통합됩니다.

SQL delta를 적극 권장 합니다. 기능 코딩을 마쳤을 때 diff 스크립트를 생성하고 해당 스크립트를 소스 제어 도구로 확인하는 데 사용합니다 (Mercurial :)).

SQL 서버와 Oracle 버전이 모두 있습니다.

Java 기반이며 jdbc를 지원하는 거의 모든 데이터베이스에서 작동 해야하는 오픈 소스 도구 liquibase에 대해 언급 한 사람이 아무도 없었는지 궁금합니다 . rails와 비교하면 ruby ​​대신 xml을 사용하여 스키마 변경을 수행합니다. 도메인 특정 언어에 대한 xml을 싫어하지만 xml의 매우 멋진 장점은 liquibase가 다음과 같은 특정 작업을 롤백하는 방법을 알고 있다는 것입니다.

<createTable tableName="USER"> 
   <column name="firstname" type="varchar(255)"/>
</createTable>

따라서 직접 처리 할 필요가 없습니다.

순수 SQL 문 또는 데이터 가져 오기도 지원됩니다.

대부분의 데이터베이스 엔진은 데이터베이스를 파일로 덤프하는 것을 지원해야합니다. 어쨌든 MySQL이 그렇다는 것을 알고 있습니다. 이것은 텍스트 파일 일 뿐이므로 Subversion 또는 사용하는 무엇이든 제출할 수 있습니다. 파일에 대한 차이점도 쉽게 실행할 수 있습니다.

SQL Server를 사용하는 경우 Data Dude (일명 Visual Studio의 Database Edition)를 이기기가 어려울 것입니다. 일단 익숙해지면 소스 제어 버전의 데이터베이스와 프로덕션 버전 간의 스키마 비교를 쉽게 수행 할 수 있습니다. 클릭 한 번으로 diff DDL을 생성 할 수 있습니다.

매우 유용한 MSDN 교육용 비디오 가 있습니다.

DBMS_METADATA와 Toad에 대해 알고 있지만 누군가 Oracle 용 Data Dude를 생각해 낼 수 있다면 인생은 정말 달콤 할 것입니다.

버전 컨트롤러에서 초기 생성 테이블 문을 만든 다음 alter table 문을 추가하되 파일을 편집하지 말고 이상적으로 순차적으로 명명 된 추가 파일이나 "변경 세트"로만 변경하면 특정 배포에 대한 모든 변경 사항을 찾을 수 있습니다.

내가 볼 수있는 가장 어려운 부분은 종속성을 추적하는 것입니다. 예를 들어 특정 배포 테이블 B를 테이블 A보다 먼저 업데이트해야 할 수 있습니다.

Oracle의 경우 스키마를 여러 개의 개별 파일 (예 : 테이블 당 하나의 파일)로 덤프 할 수있는 Toad를 사용 합니다. Perforce에서이 컬렉션을 관리하는 스크립트가 있지만 거의 모든 개정 제어 시스템에서 쉽게 수행 할 수 있어야한다고 생각합니다.

오라클 패키지 DBMS_METADATA를 살펴보십시오.

특히 다음 방법이 특히 유용합니다.

• DBMS_METADATA.GET_DDL
• DBMS_METADATA.SET_TRANSFORM_PARAM
• DBMS_METADATA.GET_GRANTED_DDL

작동 방식에 익숙해지면 (자세한 설명이 필요함) 간단한 스크립트를 작성하여 해당 메소드의 결과를 소스 제어하에 놓을 수있는 텍스트 파일로 덤프 할 수 있습니다. 행운을 빕니다!

MSSQL에 대해 이렇게 간단한 것이 있는지 확실하지 않습니다.

코딩과 병행하여 db 릴리스 스크립트를 작성하고 SS의 프로젝트 특정 섹션에 릴리스 스크립트를 유지합니다. db 변경이 필요한 코드를 변경하면 릴리스 스크립트도 동시에 업데이트합니다. 릴리스 전에는 깨끗한 dev db (프로덕션에서 구조적으로 복사)에서 릴리스 스크립트를 실행하고 최종 테스트를 수행합니다.

저는 스키마 버전을 관리 (또는 관리하려고)하는 등 몇 년 동안이 작업을 수행했습니다. 최상의 접근 방식은 사용중인 도구에 따라 다릅니다. Quest Software 도구 "Schema Manager"를 얻을 수 있다면 좋은 상태가 될 것입니다. 오라클은 "Schema Manager"라고도하는 자체의 열등한 도구를 가지고 있습니다 (많이 헷갈 리나요?).

자동화 된 도구가 없으면 (Data Dude에 대한 다른 설명 참조) 스크립트와 DDL 파일을 직접 사용하게됩니다. 접근 방식을 선택하고 문서화하고 엄격하게 따르십시오. 저는 주어진 순간에 데이터베이스를 다시 생성 할 수있는 기능을 좋아하므로 전체 데이터베이스 (DBA 인 경우) 또는 개발자 스키마 (제품에있는 경우)의 전체 DDL 내보내기를 선호합니다. -개발 모드).

All Arround Automations의 도구 인 PLSQL Developer에는 Visual Source Safe에서 정상적으로 작동하지만 훌륭하지는 않은 저장 소용 플러그인이 있습니다.

웹에서 :

버전 제어 플러그인은 PL / SQL Developer IDE >>와 Microsoft SCC 인터페이스 사양을 지원하는 모든 버전 제어 시스템 간의 긴밀한 통합을 제공합니다. >> 여기에는 Microsoft Visual SourceSafe, >> Merant PVCS 및 MKS Source Integrity와 같은 가장 널리 사용되는 버전 제어 시스템이 포함됩니다.

http://www.allroundautomations.com/plsvcs.html

ER Studio를 사용하면 데이터베이스 스키마를 도구로 전환 한 다음이를 라이브 데이터베이스와 비교할 수 있습니다.

예 : 개발 스키마를 ER Studio로 되돌리고 프로덕션과 비교하면 모든 차이점이 나열됩니다. 변경 사항을 스크립팅하거나 자동으로 푸시 할 수 있습니다.

ER Studio에 스키마가 있으면 생성 스크립트를 저장하거나 독점 바이너리로 저장하고 버전 제어에 저장할 수 있습니다. 이전 버전의 스키마로 돌아가고 싶다면 체크 아웃하고 db 플랫폼에 푸시하십시오.

Ruckusing이라는 PHP5 "데이터베이스 마이그레이션 프레임 워크"가 있습니다. 나는 그것을 사용하지 않았지만 예제 는 아이디어를 보여줍니다. 언어를 사용하여 데이터베이스를 만들면 필요할 때 소스 파일 만 추적하면됩니다.

Visual Studio에서 Microsoft SQL Server 데이터 도구 를 사용 하여 SQL Server 프로젝트의 일부로 데이터베이스 개체에 대한 스크립트를 생성 할 수 있습니다 . 그런 다음 Visual Studio에 내장 된 소스 제어 통합을 사용하여 소스 제어에 스크립트를 추가 할 수 있습니다. 또한 SQL Server 프로젝트를 사용하면 컴파일러를 사용하여 데이터베이스 개체를 확인하고 배포 스크립트를 생성하여 기존 데이터베이스를 업데이트하거나 새 데이터베이스를 만들 수 있습니다.

우리는 MS Team System Database Edition 을 매우 성공적으로 사용했습니다. TFS 버전 제어 및 Visual Studio와 어느 정도 원활하게 통합되며 저장된 procs, 뷰 등을 쉽게 관리 할 수 ​​있습니다. 충돌 해결은 고통 스러울 수 있지만 일단 완료되면 버전 기록이 완료됩니다. 그 후에는 QA 및 프로덕션으로의 마이그레이션이 매우 간단합니다.

그러나 버전 1.0 제품이라고 말하는 것이 공정하며 몇 가지 문제가없는 것은 아닙니다.

Schema Compare for Oracle은 Oracle 데이터베이스에서 다른 데이터베이스로 변경 사항을 마이그레이션하도록 특별히 설계된 도구입니다. 전체 기능 평가판을 위해 소프트웨어를 사용할 수있는 다운로드 링크를 보려면 아래 URL을 방문하십시오.

http://www.red-gate.com/Products/schema_compare_for_oracle/index.htm

테이블 변경에 대한 VCS가 없으면 위키에 기록했습니다. 적어도 나는 그것이 언제 그리고 왜 변경되었는지 볼 수 있습니다. 모든 사람이 그렇게하지 않고 여러 제품 버전을 사용하고 있기 때문에 완벽하지는 않지만 아무것도없는 것보다 낫습니다.

두 가지 접근 방식 중 하나를 권장합니다. 먼저 Sybase의 PowerDesigner에 투자하십시오 . 기업용 에디션. 이를 통해 물리적 데이터 모델 등을 설계 할 수 있습니다. 그러나 모델을 체크인 할 수있는 저장소가 함께 제공됩니다. 각각의 새로운 체크인은 새 버전이 될 수 있으며 모든 버전을 다른 버전과 비교할 수 있으며 당시 데이터베이스에있는 것과도 비교할 수 있습니다. 그런 다음 모든 차이점 목록을 표시하고 마이그레이션해야하는 항목을 묻는 메시지를 표시 한 다음이를 수행하기위한 스크립트를 작성합니다. 저렴하지는 않지만 두 배의 가격으로 저렴하고 ROI는 약 6 개월입니다.

다른 아이디어는 DDL 감사 (Oracle에서 작동)를 켜는 것입니다. 이렇게하면 변경할 때마다 테이블이 생성됩니다. 마지막으로 데이터베이스 변경 사항을 prod로 이동 한 타임 스탬프에서 변경 사항을 쿼리하면 수행 한 모든 작업의 ​​순서가 지정된 목록이 표시됩니다. create table foo와 같은 제로섬 변경을 제거하기위한 몇 가지 where 절; 드롭 테이블 foo; 모드 스크립트를 쉽게 만들 수 있습니다. 위키에 변경 사항을 유지하는 이유는 작업의 두 배입니다. 데이터베이스에서 추적하도록하십시오.

두 권의 책 추천 : Ambler와 Sadalage의 "Refactoring Databases"와 Ambler의 "Agile Database Techniques".

누군가가 Rails 마이그레이션을 언급했습니다. Rails 애플리케이션 외부에서도 훌륭하게 작동한다고 생각합니다. Rails로 이동하는 과정에있는 SQL Server와 함께 ASP 응용 프로그램에서 사용했습니다. 마이그레이션 스크립트 자체를 VCS로 확인합니다. 여기 실용 데이브 토마스에 의해 게시물 주제에가.