문제

대부분의 프로젝트에서 SQL Server 2000/2005 및 Vault 또는 SVN을 사용합니다. 두 소스 제어 시스템에서 데이터베이스 스키마/PREC 변경을 캡처하기위한 괜찮은 솔루션을 찾지 못했습니다.

우리의 현재 솔루션은 매우 번거롭고 시행하기가 어렵습니다 (변경 한 객체를 스크립트하고 데이터베이스에 커밋).

우리는 일부 사용자 정의 개발 로이 문제를 해결하는 방법에 대한 많은 아이디어를 가지고 있지만 기존 도구를 설치하고 싶습니다 (유료 도구는 괜찮습니다).

그래서 : 데이터베이스 코드 변경을 어떻게 추적합니까? 권장 도구가 있습니까?


편집하다:

모든 제안에 감사드립니다. 시간 제약으로 인해 여기에 내 자신을 굴리지 않을 것입니다. 그리고 대부분의 제안은 개발자가 일부 절차를 따르도록 요구한다는 결함이 있습니다.

대신, 이상적인 솔루션은 변경 사항을 위해 SQL 데이터베이스를 모니터링하고 SCM에 대한 감지 된 변경 사항을 충족시킵니다. 예를 들어, SQL Server에 변경을 한 사용자와 DML 변경을 기록 할 수있는 애드온이 있다면 해당 객체의 스크립트를 SCM에 커밋하면 스릴이 있습니다.

우리는 두 가지 시스템에 대해 내부적으로 이야기했습니다. 1. SQL 2005에서는 객체 권한을 사용하여 "체크 아웃"을 할 때까지 객체 변경을 제한합니다. 그런 다음 체크인 절차가 SCM으로 스크립트됩니다. 2. 예정된 작업을 실행하여 변경 사항을 감지하고 (익명으로) SCM에 헌신하십시오.

사용자 활동 부품을 건너 뛰고 시스템 이이 모든 것을 자동으로 처리하도록 할 수 있다면 좋을 것입니다.

도움이 되었습니까?

해결책

Visual Studio Database Edition을 사용하여 데이터베이스를 스크립팅하십시오. 매력처럼 작동하며 소스 제어 시스템을 사용할 수 있습니다. 물론 플러그인이있는 경우 가장 좋습니다. 이 도구에는 다른 유용한 기능도 있습니다. 이 위대한 블로그 게시물에서 여기에서 확인하십시오

http://www.vitalygorn.com/blog/post/2008/01/handling-database-easilily-with-visual-studio-2008.aspx

또는 공식 문서는 MSDN을 확인하십시오

다른 팁

다양한 타사 도구를 사용하여 SSM에서 직접 데이터베이스 변경을 추적 할 수 있습니다. ApexSQL 소스 컨트롤 버전 작성에 포함 된 모든 데이터베이스 개체를 자동으로 스크립트합니다. 도구는 커밋을 자동으로 수행 할 수 없습니다. 대신, 사용자는 어떤 변경 사항을 커밋 할 것인지 선택해야합니다.

리포지토리에서 변경 사항을 얻을 때 APEXSQL 소스 컨트롤은 SQL 데이터베이스 참조 무결성을 알고 있습니다. 따라서 트랜잭션에 래핑 될 모든 종속 객체를 포함하여 동기화 스크립트를 생성하므로 오류가 발생하지 않거나 선택한 변경 사항이 적용되지 않은 경우 모든 변경 사항이 적용됩니다. 어쨌든 데이터베이스 무결성은 영향을받지 않습니다.

비주얼 스튜디오 데이터베이스 프로젝트가 소스 제어 딜레마에 대한 합리적인 솔루션이라고 생각합니다. 올바르게 설정되면 IDE에서 데이터베이스에 대해 스크립트를 실행할 수 있습니다. 스크립트가 오래된 경우 최신 정보를 얻고 DB에 대해 실행하십시오. 필요한 경우 모든 객체를 재현하는 스크립트가 있어도 새 개체는이 스크립트에도 손으로 추가해야하지만 한 번만 추가해야합니다.

나는 모든 테이블, Proc 및 기능이 자체 파일에있는 것을 좋아합니다.

가난한 사람의 솔루션 중 하나는 최신 DB 스키마를 파일에 버리고 해당 파일을 코드와 함께 SVN 저장소에 커밋하는 사전 커밋 후크 스크립트를 추가하는 것입니다. 그런 다음 DB 스키마 파일을 모든 개정판에서 차단할 수 있습니다.

나는 단지 SQL-Alter-Statement를 완전한 SQL-CreatedB-Statement에 추가로 커밋합니다.

처음부터 직접 굴리는 것은 그다지 가능하지 않지만 SQL 비교 도구를 사용하는 경우 Redgate SQL SDK 비교 변경 파일을 생성하려면 원하는대로 오랫동안 절반이 걸리지 않아도됩니다. 그런 다음 해당 파일을 소스 컨트롤로 확인하십시오. 나는 단 몇 시간 만에 개발 시스템에서 라이브 시스템으로의 변경 사항을 업데이트하기 위해 비슷한 것을 굴 렸습니다.

환경에서는 DB를 수동으로 변경하지 않습니다. 모든 변경 사항은 릴리스 시간에 스크립트에 의해 수행되며 스크립트는 버전 제어 시스템에 보관됩니다. 이 절차의 중요한 부분 중 하나는 데이터 손실없이 모든 스크립트를 동일한 DB에 대해 다시 실행할 수 있는지 확인하는 것입니다. 예를 들어, 열을 추가하면 열이 이미 있으면 아무것도하지 않아야합니다.

"제안은 DEV가 일부 절차를 따르도록 요구한다는 결함이 있습니다"에 대한 귀하의 의견은 실제로 이야기입니다. 결함이 아니라 기능입니다. 버전 제어는 개발자가 다음 절차를 수행하는 데 도움이되고 절차를 덜 고통스럽게 만듭니다. 절차를 따르고 싶지 않다면 버전 제어가 필요하지 않습니다.

SQL2000에서 각 객체를 자체 파일로 생성합니다, 그런 다음 소스 컨트롤에 모두 확인하십시오. 소스 제어가 변경 기록을 처리하도록하십시오.

SQL 2005에서는 모든 객체를 별도의 파일로 생성하려면 약간의 코드를 작성해야합니다.

하나의 프로젝트에서 나는 데이터베이스의 모든 중요한 데이터를 외부 장소에서 자동으로 재현 할 수 있다는 설계에주의를 기울여주의를 기울였습니다. 시작시 응용 프로그램은 누락 된 경우 데이터베이스를 생성하고 응용 프로그램 소스 코드의 스키마를 사용하여 외부 데이터 소스에서 채워집니다 (따라서 응용 프로그램과 함께 버전). 데이터베이스 스토어 이름 (대부분의 데이터베이스 관리자가 여러 데이터베이스를 허용하지만 SQLITE 파일 이름)에는 스키마 버전이 포함되며 스키마 변경을 할 때마다 스키마 버전이 증가합니다. 이는 새로운 데이터베이스 스토어가 자동으로 생성되고 채워진 다른 스키마를 사용하여 응용 프로그램을 새 버전으로 다시 시작할 때 의미합니다. 구식 스키마로 배포를 되돌려 야한다면 이전 버전의 새로운 실행은 이전 데이터베이스 스토어를 사용하는 것이므로 문제가 발생한 경우 빠른 다운 그레이드를 수행합니다.

기본적으로 데이터베이스는 기존 애플리케이션 힙처럼 작용하며 지속성, 트랜잭션 안전, 정적 타이핑 (파이썬을 사용하기 때문에 편리함) 및 고유성 제약 조건의 장점이 있습니다. 그러나 우리는 데이터베이스를 삭제하고 다시 시작하는 것에 대해 전혀 걱정하지 않으며, 사람들은 데이터베이스에서 수동 해킹을 시도하면 다음 배포에서 프로세스 상태의 해킹이 되돌아 갈 것임을 알고 있습니다. 다음 재시작에.

데이터베이스 파일 이름을 전환하고 응용 프로그램을 다시 시작하고 자체적으로 재건되므로 마이그레이션 스크립트가 필요하지 않습니다. 클라이언트 당 하나의 데이터베이스를 사용하도록 응용 프로그램 인스턴스가 샤드를 제공하는 데 도움이됩니다. 또한 데이터베이스 백업의 필요성을 줄입니다.

외부 소스에서 데이터베이스 빌드가 응용 프로그램을 줄일 수 있도록하는 것보다 시간이 오래 걸리면이 접근 방식이 작동하지 않습니다.

.NET을 사용하고 있고 접근 Rails가 마이그레이션을 사용하는 것처럼 보이는 경우 권장합니다. migrator.net.

나는 a를 찾았다 좋은 튜토리얼 그것은 Visual Studio에서 그것을 설정하는 것을 넘어냅니다. 또한 참조 할 샘플 프로젝트를 제공합니다.

데이터베이스를 업데이트하는 사용자 정의 도구를 개발했습니다. 데이터베이스 스키마는 데이터베이스-중립 XML 파일에 저장된 다음 도구에 의해 읽고 처리됩니다. 스키마는 SVN에 저장되어 변경된 내용을 보여주기 위해 적절한 주석을 추가합니다. 그것은 우리에게 꽤 잘 작동합니다.

이런 종류의 솔루션은 대부분의 프로젝트에서 확실히 과잉이지만 때때로 인생이 더 쉬워집니다.

당사의 DBA는 주기적으로 SVN의 내용에 대해 Prod를 점검하고 소스 제어가 아닌 객체를 삭제합니다. Devlopers가 소스 제어에 무언가를 다시 넣는 것을 잊지 않기 전에 한 번만 걸립니다.

우리는 또한 우리의 개발자들은 자체 권리가 없기 때문에 스크립트없이 객체를 대본으로 옮기는 것을 허용하지 않습니다. 이것은 시행하기 쉽습니다.

삽입 업데이트 및 삭제와 같은 모든 변경 사항을 추적하려면 SVN에 대한 많은 오버 헤드가 나타납니다. 스키마를 변경하는 (Alter, Drop, Create)와 같은 DDL 변경 만 추적하는 것이 좋습니다. 테이블과 트르거를 만들어 해당 테이블에 데이터를 삽입 하여이 스키마 추적을 쉽게 수행 할 수 있습니다. 당신이 원할 때마다 당신이 그 테이블에서 쿼리하여 변경 상태를 얻을 수 있습니다. 많은 예가 있습니다. 여기 그리고 여기

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top