데이터베이스 항목에 소스 제어를 사용합니까? [닫은]

데이터베이스 스키마 변경을 버전 화하기위한 견고한 프로세스가 없기 때문에 상점에 문제가 있다고 생각합니다. 우리는 많은 백업을 수행하기 때문에 어느 정도 보장을받을 수 있지만이 방법으로 마지막 방어선에 의존하는 것은 나쁜 습관입니다.

놀랍게도 이것은 일반적인 스레드 인 것 같습니다. 데이터베이스가 자주 바뀌지 않고 기본적으로 세심한주의를 기울이기 때문에이 문제를 무시한다고 말한 많은 상점.

그러나 나는 그 이야기가 어떻게 진행되는지 알고 있습니다. 상황이 잘못 정렬되고 문제가 발생하기까지는 시간 문제 일뿐입니다.

이에 대한 모범 사례가 있습니까? 당신을 위해 일한 몇 가지 전략은 무엇입니까?

버전 관리에서 데이터베이스 가져 오기를 읽어야 합니다 . K. Scott Allen의 일련의 게시물을 확인하십시오.

버전 관리와 관련하여 데이터베이스는 종종 2 차 또는 3 차 시민입니다. 내가 본 바에 따르면, 백만 년 안에 버전 제어없이 코드를 작성하는 것을 전혀 생각하지 않는 팀은 애플리케이션이 의존하는 중요한 데이터베이스를 중심으로 버전 제어가 필요하다는 것을 완전히 잊을 수 있습니다. 데이터베이스가 나머지 코드와 정확히 동일한 수준의 소스 제어에 있지 않을 때 어떻게 소프트웨어 엔지니어를 부르고 똑바로 얼굴을 유지할 수 있는지 잘 모르겠습니다. 이런 일이 일어나지 않도록하십시오. 데이터베이스를 버전 관리하에 두십시오.

데이터베이스 자체? 아니

정적 데이터 삽입, 저장 프로 시저 등을 포함하여 스크립트를 작성하는 스크립트 물론이야. 그들은 텍스트 파일이며 프로젝트에 포함되어 있으며 다른 모든 것과 마찬가지로 체크인 및 체크 아웃됩니다.

물론 이상적인 세계에서는 데이터베이스 관리 도구가이를 수행합니다. 그러나 당신은 그것에 대해 훈련을 받아야합니다.

저는 Rails ActiveRecord 마이그레이션을 정말 좋아합니다. DML을 루비 스크립트로 추상화 한 다음 소스 리포지토리에서 쉽게 버전을 지정할 수 있습니다.

그러나 약간의 작업으로 동일한 작업을 수행 할 수 있습니다. 모든 DDL 변경 사항 (ALTER TABLE 등)은 텍스트 파일에 저장할 수 있습니다. 파일 이름에 번호 시스템 (또는 날짜 스탬프)을 유지하고 순서대로 적용하십시오.

Rails는 마지막으로 적용된 마이그레이션을 추적하는 'version'테이블도 DB에 있습니다. 당신도 똑같이 할 수 있습니다.

소스 제어를 사용하여 데이터베이스 변경을 관리하기 위해 LiquiBase 를 확인하십시오 .

프로덕션 데이터베이스를 변경하기 위해 로그인 한 후 "ALTER TABLE"명령을 입력하면 안됩니다. 현재 프로젝트에는 모든 고객 사이트에 데이터베이스가 있으므로 데이터베이스에 대한 모든 변경은 두 곳, 새 고객 사이트에 새 데이터베이스를 만드는 데 사용되는 덤프 파일 및 실행되는 업데이트 파일로 이루어집니다. 모든 업데이트에서 현재 데이터베이스 버전 번호를 파일에서 가장 높은 번호와 비교하여 확인하고 데이터베이스를 적절하게 업데이트합니다. 예를 들어 마지막 업데이트는 다음과 같습니다.

if [ $VERSION \< '8.0.108' ] ; then
  psql -U cosuser $dbName << EOF8.0.108
    BEGIN TRANSACTION;
    --
    -- Remove foreign key that shouldn't have been there.
    -- PCR:35665
    --
    ALTER TABLE     migratorjobitems
    DROP CONSTRAINT migratorjobitems_destcmaid_fkey;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.108'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.108
fi

if [ $VERSION \< '8.0.109' ] ; then
  psql -U cosuser $dbName << EOF8.0.109
    BEGIN TRANSACTION;
    --
    -- I missed a couple of cases when I changed the legacy playlist
    -- from reporting showplaylistidnum to playlistidnum
    --
    ALTER TABLE     featureidrequestkdcs
    DROP CONSTRAINT featureidrequestkdcs_cosfeatureid_fkey;
    ALTER TABLE     featureidrequestkdcs
    ADD CONSTRAINT  featureidrequestkdcs_cosfeatureid_fkey
    FOREIGN KEY     (cosfeatureid)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    --
    ALTER TABLE     ticket_system_ids
    DROP CONSTRAINT ticket_system_ids_showplaylistidnum_fkey;
    ALTER TABLE     ticket_system_ids
    RENAME          showplaylistidnum
    TO              playlistidnum;
    ALTER TABLE     ticket_system_ids
    ADD CONSTRAINT  ticket_system_ids_playlistidnum_fkey
    FOREIGN KEY     (playlistidnum)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.109'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.109
fi

이 작업을 수행하는 더 좋은 방법이 있다고 확신하지만 지금까지는 효과가 있습니다.

예. 코드는 코드입니다. 경험상 , 개발 또는 프로덕션 머신을 보지 않고도 처음부터 애플리케이션을 빌드하고 배포 할 수 있어야 합니다.

내가 본 모범 사례는 준비 서버에서 데이터베이스를 스크랩하고 다시 작성하는 빌드 스크립트를 만드는 것입니다. 각 반복에는 데이터베이스 변경을위한 폴더가 주어졌으며 모든 변경 사항은 "Drop ... Create"로 스크립트되었습니다. 이렇게하면 버전을 만들려는 폴더로 빌드를 지정하여 언제든지 이전 버전으로 롤백 할 수 있습니다.

나는 이것이 NaNt / CruiseControl로 이루어 졌다고 생각합니다.

예, 데이터베이스 버전을 관리하는 것이 중요하다고 생각합니다. 데이터가 아니라 특정 스키마입니다.

Ruby On Rails에서 이는 "마이그레이션"프레임 워크에서 처리합니다. db를 변경할 때마다 변경 사항을 적용하고 소스 제어에서 점검하는 스크립트를 작성하십시오.

내 상점은 그 아이디어를 너무 좋아서 쉘 스크립트 와 Ant를 사용하여 Java 기반 빌드에 기능을 추가했습니다 . 프로세스를 배포 루틴에 통합했습니다. 즉시 사용 가능한 DB 버전 관리를 지원하지 않는 다른 프레임 워크에서 동일한 작업을 수행하는 스크립트를 작성하는 것이 매우 쉽습니다.

Visual Studio의 새로운 데이터베이스 프로젝트는 소스 제어 및 변경 스크립트를 제공합니다.

데이터베이스를 비교하고 하나의 스키마를 다른 스키마로 변환하거나 한 데이터를 다른 데이터와 일치하도록 업데이트하는 스크립트를 생성 할 수있는 유용한 도구가 있습니다.

db 스키마는 "파쇄"되어 DB를 설명하는 DDL 명령 당 하나씩 많은 작은 .sql 파일을 작성합니다.

+ 톰

추가 정보 2008-11-30

나는 지난해 개발자로 그것을 사용하고 정말 좋아합니다. 개발 작업을 프로덕션과 쉽게 비교하고 릴리스에 사용할 스크립트를 생성 할 수 있습니다. DBA가 "엔터프라이즈 유형"프로젝트에 필요한 기능이 없는지 모르겠습니다.

스키마는 SQL 파일로 "파쇄"되므로 소스 컨트롤이 제대로 작동합니다.

한 가지 문제는 db 프로젝트를 사용할 때 다른 사고 방식이 필요하다는 것입니다. 이 도구에는 VS에 "db 프로젝트"가 있는데, 이는 단지 SQL 일뿐 아니라 스키마 및 기타 관리 데이터가 있지만 자동으로 생성 된 로컬 데이터베이스입니다. 앱 데이터 개발 작업. 자동으로 생성 된 db에 대해서는 거의 알지 못하지만 DB를 알고 있어야합니다. 이 특별한 DB는 이름에 Guid가 있기 때문에 명확하게 알아볼 수 있습니다.

VS DB 프로젝트는 다른 팀 구성원이 로컬 프로젝트 / 관련 DB에 변경 한 DB 변경 사항을 통합하는 훌륭한 작업을 수행합니다. 그러나 프로젝트 스키마를 로컬 dev db 스키마와 비교하고 모드를 적용하려면 추가 단계를 수행해야합니다. 말이 되겠지만 처음에는 어색해 보입니다.

DB 프로젝트는 매우 강력한 도구입니다. 스크립트를 생성 할뿐만 아니라 즉시 적용 할 수 있습니다. 프로덕션 DB를 사용하지 마십시오. ;)

나는 VS DB 프로젝트를 정말로 좋아하며 앞으로 모든 DB 프로젝트 에이 도구를 사용할 것으로 기대합니다.

+ 톰

개발 팀에 SQL 데이터베이스 소스 제어 관리 시스템을 사용하도록 요구하는 것은 문제가 발생하는 것을 막는 마법의 총알이 아닙니다. 자체적으로 데이터베이스 소스 제어는 개발자가 별도의 SQL 스크립트에서 오브젝트에 대한 변경 사항을 저장하고 소스 제어 시스템 클라이언트를 열고 클라이언트를 사용하여 SQL 스크립트 파일을 체크인 한 후 추가 오버 헤드를 발생시킵니다. 라이브 데이터베이스에 변경 사항을 적용하십시오.

ApexSQL Source Control 이라는 SSMS 애드 인 사용을 제안 할 수 있습니다 . 이를 통해 개발자는 SSMS에서 직접 마법사를 통해 데이터베이스 개체를 소스 제어 시스템과 쉽게 매핑 할 수 있습니다. 추가 기능에는 TFS, Git, Subversion 및 기타 SC 시스템에 대한 지원이 포함됩니다. 소스 제어 정적 데이터에 대한 지원도 포함합니다.

ApexSQL 소스 제어를 다운로드하여 설치 한 후 버전 제어하려는 데이터베이스를 마우스 오른쪽 단추로 클릭하고 SSMS에서 ApexSQL 소스 제어 하위 메뉴로 이동하십시오. 데이터베이스를 소스 제어에 링크 옵션을 클릭하고 소스 제어 시스템 및 개발 모델을 선택하십시오. 그런 다음 선택한 소스 제어 시스템에 대한 로그인 정보와 저장소 문자열을 제공해야합니다.

자세한 내용은이 기사를 참조하십시오. http://solutioncenter.apexsql.com/sql-source-control-reduce-database-development-time/

작성 / 업데이트 스크립트와 샘플 데이터를 생성하는 스크립트를 저장하여 수행합니다.

예, SQL을 빌드의 일부로 유지하여 SQL을 유지합니다. DROP.sql, CREATE.sql, USERS.sql, VALUES.sql을 유지하고 버전을 제어하므로 태그가있는 버전으로 되돌릴 수 있습니다.

또한 필요할 때마다 DB를 다시 만들 수있는 개미 작업도 있습니다.

또한 SQL에 소스 코드와 함께 태그가 추가됩니다.

내가 프로젝트에서 사용한 가장 성공적인 계획은 백업과 차등 SQL 파일을 결합한 것입니다. 기본적으로 우리는 모든 릴리스 후에 db를 백업하고 SQL 덤프를 수행하여 필요할 때 처음부터 빈 스키마를 만들 수 있습니다. 그런 다음 DB를 변경해야 할 때마다 버전 제어 하의 sql 디렉토리에 alter scrip을 추가하십시오. 우리는 항상 파일 이름 앞에 시퀀스 번호 또는 날짜를 붙일 것이므로 첫 번째 변경은 01_add_created_on_column.sql과 같으며 다음 스크립트는 02_added_customers_index입니다. CI 머신은이를 확인하고 백업에서 복원 된 새로운 db 사본에서 순차적으로 실행합니다.

또한 개발자가 단일 명령으로 로컬 db를 현재 버전으로 다시 초기화하는 데 사용할 수있는 일부 스크립트가 있습니다.

우리는 모든 dabase 생성 객체를 소스 제어합니다. 그리고 개발자가 정직하게 유지하기 위해 (소스 컨트롤에 있지 않은 객체를 만들 수 있기 때문에) 우리의 dbas는 주기적으로 소스 컨트롤에없는 것을 찾습니다.

SchemaBank 를 사용 하여 모든 데이터베이스 스키마 변경 사항을 버전 관리합니다.

• 1 일부터 DB 스키마 덤프를 가져옵니다.
• 웹 브라우저를 사용하여 스키마 디자인을 변경하기 시작했습니다 (SaaS / 클라우드 기반이기 때문에)
• 내 DB 서버를 업데이트하려고 할 때 변경 (SQL) 스크립트를 생성하여 DB에 적용합니다. Schemabank에서는 업데이트 스크립트를 생성하기 전에 작업을 버전으로 커밋해야합니다. 나는 이런 종류의 연습을 좋아하므로 필요할 때 항상 추적 할 수 있습니다.

우리 팀 규칙은 디자인 작업을 먼저 저장하지 않고 DB 서버를 직접 만지지 않는 것입니다. 그러나 누군가가 편리한 이유로 규칙을 어 기고 싶은 유혹을받을 수 있습니다. 스키마 덤프를 다시 schemabank로 가져 와서 diff를 수행하고 불일치가 발견되면 누군가를 때려 눕 힙니다. db와 schema 디자인을 동기화하기 위해 alter script를 생성 할 수는 있지만, 그 스크립트는 싫습니다.

그런데 버전 관리 트리 내에 브랜치를 만들어 스테이징 용과 프로덕션 용으로 하나를 유지할 수있게했습니다. 그리고 샌드 박스를 코딩하기위한 것입니다.

버전 관리 및 변경 관리 기능을 갖춘 매우 깔끔한 웹 기반 스키마 디자인 도구입니다.

베어 메탈에서 데이터 자체를 빼고 DB를 재생성하는 데 필요한 모든 것이 있습니다. 나는 그것을 할 수있는 많은 방법이 있다고 확신하지만, 모든 스크립트 등은 Subversion에 저장되며 DB 구조를 다시 빌드 할 수 있으며 Subversion에서 모든 것을 꺼내고 설치 프로그램을 실행하여 DB 구조를 재구성 할 수 있습니다.

나는 일반적으로 모든 변경 사항에 대해 SQL 스크립트를 작성하고 다른 변경 사항을 되돌리고 해당 스크립트를 버전 제어 상태로 유지합니다.

그런 다음 요청시 새로운 최신 데이터베이스를 생성 할 수 있으며 개정간에 쉽게 이동할 수 있습니다. 릴리스를 할 때마다 스크립트를 한꺼번에 모으고 (약간의 수동 작업을 수행하지만 실제로는 거의 어렵지 않습니다 ) 버전간에 변환 할 수있는 스크립트 세트도 있습니다.

예, 말하기 전에 이것은 Rails와 다른 것들과 매우 유사하지만 꽤 잘 작동하는 것 같습니다. 그래서 나는 뻔뻔스럽게 아이디어를 들었다는 것을 인정하는 데 아무런 문제가 없습니다 :)

MySQL Workbech에서 내 보낸 SQL CREATE 스크립트를 사용하고 "Export SQL ALTER"기능을 사용하여 일련의 작성 스크립트 (물론 번호가 매겨 짐)와 스크립트간에 변경 사항을 적용 할 수있는 alter 스크립트가 생깁니다.

3.- SQL ALTER 스크립트 내보내기 일반적으로 모델에 대한 변경 사항을 반영하여 ALTER TABLE 문을 직접 작성해야합니다. 그러나 당신은 똑똑하고 Workbench가 당신을 위해 열심히 일하게 할 수 있습니다. 기본 메뉴에서 File-> Export-> Forward Engineer SQL ALTER Script…를 선택하십시오.

현재 모델과 비교할 SQL CREATE 파일을 지정하라는 메시지가 표시됩니다.

1 단계에서 SQL CREATE 스크립트를 선택하십시오. 그러면 도구가 ALTER TABLE 스크립트를 생성하고 데이터베이스에 대해이 스크립트를 실행하여 최신 상태로 만들 수 있습니다.

MySQL Query Browser 또는 mysql 클라이언트를 사용하여이 작업을 수행 할 수 있습니다. 모델과 데이터베이스가 동기화되었습니다!

출처 : MySQL Workbench Community Edition : 스키마 동기화 가이드

물론이 모든 스크립트는 버전 관리하에 있습니다.

예, 항상 요 필요할 때마다 유용한 샘플 데이터 세트를 사용하여 프로덕션 데이터베이스 구조를 다시 작성할 수 있어야합니다. 그렇지 않으면 시간이 지남에 따라 사물을 잊어 버리는 사소한 변경 사항이 생기면 언젠가는 물린 채 큰 시간을 보냅니다. 당신이 필요하다고 생각하지 않을 수도 있지만 그것을하는 날의 보험은 10 배 이상 가격이 가치가 있습니다!

데이터베이스 모델 자체에 대해 많은 논의가 있었지만 필요한 데이터는 .SQL 파일로 유지됩니다.

예를 들어, 유용한 응용 프로그램을 설치하려면 다음이 필요합니다.

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('AUD', 'Australian Dollars');

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('USD', 'US Dollars');

우리는 currency.sqlsubversion 이라는 파일을 가질 것 입니다. 빌드 프로세스의 수동 단계로서 이전 currency.sql을 최신 통화와 비교하고 업그레이드 스크립트를 작성합니다.

우리는 데이터베이스를 둘러싼 모든 것을 버전 화하고 소스 제어합니다.

• DDL (작성 및 변경)
• DML (참조 데이터, 코드 등)
• 데이터 모델 변경 (ERwin 또는 ER / Studio 사용)
• 데이터베이스 구성 변경 (권한, 보안 개체, 일반 구성 변경)

Change Manager와 일부 사용자 지정 스크립트를 사용하여 자동화 된 작업으로이 모든 작업을 수행합니다. 변경 관리자는 이러한 변경 사항을 모니터링하고 변경 사항을 알려줍니다.

모든 DB는 소스 제어를 받아야하며 개발자는 로컬 데이터베이스를 처음부터 쉽게 만들 수 있어야합니다. Visual Studio for Database Professionals에서 영감을 얻어 MS SQL 데이터베이스를 스크립팅하고 로컬 DB 엔진에 쉽게 배포 할 수있는 오픈 소스 도구를 만들었습니다. http://dbsourcetools.codeplex.com/을 시도 하십시오 . 즐거운 시간 보내세요-네이선

데이터베이스가 SQL Server 인 경우 원하는 솔루션이있을 수 있습니다. SQL Source Control 1.0이 릴리스되었습니다.

http://www.red-gate.com/products/SQL_Source_Control/index.htm

이것은 SSMS에 통합되어 데이터베이스 개체와 VCS 사이에 접착제를 제공합니다. '스크립트 작성'은 투명하게 이루어지며 (후드에서 SQL 비교 엔진을 사용함) 개발자가 프로세스를 채택하지 않도록 사용하는 것이 매우 간단해야합니다.

대체 Visual Studio 솔루션은 ReadyRoll 이며, 이는 SSDT 데이터베이스 프로젝트의 하위 유형으로 구현됩니다. 이는 DevOps 팀의 자동화 요구 사항에 더 적합한 마이그레이션 중심 접근 방식을 취합니다.

모든 개체 (테이블 정의, 인덱스, 저장 프로 시저 등)를 스크립팅하여 데이터베이스 스키마를 소스 제어합니다. 그러나 데이터 자체는 정기적 인 백업에만 의존합니다. 이렇게하면 모든 구조적 변경 사항이 올바른 개정 내역으로 캡처되지만 데이터가 변경 될 때마다 데이터베이스에 부담이되지 않습니다.

우리 회사에서는 데이터베이스 변경 스크립트를 사용합니다. 스크립트가 실행될 때 해당 이름이 데이터베이스에 저장되고 해당 행이 제거되지 않으면 다시 실행되지 않습니다. 스크립트는 날짜, 시간 및 코드 분기를 기준으로 이름이 지정되므로 제어 된 실행이 가능합니다.

스크립트가 실제 환경에서 실행되기 전에 많은 테스트가 수행되므로 "oopsies"는 일반적으로 개발 데이터베이스에서만 발생합니다.

모든 데이터베이스를 소스 제어로 옮기는 중입니다. 우리는 sqlcompare를 사용하여 데이터베이스 (불행히도 전문 판 기능)를 스크립팅하고 그 결과를 SVN에 넣습니다.

구현의 성공 여부는 조직의 문화와 관행에 크게 좌우됩니다. 여기서 사람들은 응용 프로그램 당 데이터베이스를 만드는 것을 믿습니다. 대부분의 응용 프로그램에서 사용되는 공통 데이터베이스 세트가 있으며 데이터베이스 간 종속성이 많이 발생합니다 (일부는 순환 형). 시스템의 데이터베이스 간 종속성으로 인해 데이터베이스 스키마를 소스 제어에 배치하는 것은 매우 어려운 일입니다.

행운을 빕니다. 문제를 빨리 발견할수록 빨리 문제를 해결할 수 있습니다.

ThoughtWorks ( http://dbdeploy.com/) 의 dbdeploy 도구를 사용했습니다 . 마이그레이션 스크립트 사용을 권장합니다. 각 릴리스마다 변경 스크립트를 단일 파일로 통합하여 이해를 쉽게하고 DBA가 변경을 '축복'할 수 있도록했습니다.

이것은 항상 나에게 큰 성가심이었습니다. 개발 데이터베이스를 빠르게 변경하고 저장 (변경 스크립트 저장을 잊어 버린)하는 것이 너무 쉬운 것처럼 보이면 붙어 있습니다. 스크립트를 작성하는 데 많은 시간이 들었지만 방금 수행 한 작업을 취소하고 다시 실행하여 변경 스크립트를 작성하거나 다시 원할 경우 처음부터 작성할 수 있습니다.

과거에 내가 사용했던 도구 중 일부는 SQL Delta입니다. 두 데이터베이스 (SQL 서버 / 오라클이 믿는)의 차이점을 보여주고 A-> B를 마이그레이션하는 데 필요한 모든 변경 스크립트를 생성합니다. 또 다른 좋은 점은 프로덕션 (또는 테스트) DB와 개발 DB 간의 데이터베이스 내용 간의 모든 차이점을 보여주는 것입니다. 점점 더 많은 앱이 데이터베이스 테이블에서의 실행에 중요한 구성 및 상태를 저장하기 때문에 적절한 행을 제거, 추가 및 변경하는 변경 스크립트를 작성하는 것은 정말 어려울 수 있습니다. SQL Delta는 변경, 추가, 삭제 된 Diff 도구에서와 같이 데이터베이스의 행을 표시합니다.

훌륭한 도구입니다. 링크는 다음과 같습니다. http://www.sqldelta.com/

RedGate는 훌륭합니다. 데이터베이스 변경 (작은 이진 파일)을 만들 때 새 스냅 샷을 생성하고 해당 파일을 프로젝트에 리소스로 유지합니다. 데이터베이스를 업데이트해야 할 때마다 RedGate 툴킷을 사용하여 데이터베이스를 업데이트하고 빈 데이터베이스에서 새 데이터베이스를 만들 수 있습니다.

RedGate는 또한 데이터 스냅 샷을 만들지 만 개인적으로 작업하지는 않았지만 강력합니다.

참고 이것은 또한 Dana에 의해 며칠 전에 제기되었습니다 ... 소스 제어의 스토어드 프로 시저 / DB 스키마