웹 애플리케이션에서 데이터베이스 구조를 어떻게 최신 상태로 유지합니까?

Question

애플리케이션 배포 후 데이터가 변경된 경우 데이터베이스를 어떻게 최신 상태로 유지합니까?

즉, 테이블을 추가하거나 제거할 수 있다는 것입니다. 이는 간단한 작업입니다.기존 테이블을 변경하는 것도 간단할 수 있습니다.하지만 구조를 자주 변경하는 경우 이를 어떻게 제어할 수 있습니까?

저는 데이터베이스에 현재 데이터베이스 버전이 포함된 테이블을 유지하곤 했습니다.그런 다음 모든 업그레이드는 새 테이블 생성, 열 추가 또는 데이터 이동 등의 작업을 수행하는 SQL 파일이었습니다.파일 이름은 해당 버전에 따라 지정되었습니다. 따라서 업그레이드 스크립트가 데이터베이스 버전 10을 얻은 경우 11.sql의 모든 파일을 N.sql로 가져와 동시에 데이터베이스 버전 번호를 증가시키면서 각 파일을 적용했습니다.

이것은 잘 작동하는 것 같지만, 그러한 작업에 대한 귀하의 전략이 무엇인지 궁금합니다.
또한 이 시스템은 하나의 "패치"로 테이블을 정규화한 다음 어떤 이유로든 다시 비정규화하는 경우 완벽해 보이지 않습니다.그러면 2번 완료됩니다.

하지만 뭔가를 변경할 때마다 완전한 업그레이드 스크립트를 작성하는 것은 힘들고 오류가 발생하기 쉬운 것 같습니다.적어도 그러한 원자 변화 이상입니다.

또한 고객마다 언제든지 다른 데이터베이스 버전이 실행될 것으로 예상할 수 있으므로 어느 지점에서나 올라갈 수 있는 방법이 있어야 합니다.

Answer 1

개인적으로 나는 당신이 나열한 것과 매우 유사한 프로세스를 사용합니다. 변화에 대한 당신의 주장을 볼 수 있지만, 변경을 거의하지 않고 생산 사이트의 이전 방식으로 다시 변경하지 않습니다. 테스트에서 그렇습니다. 그렇습니다. 그러나 실제 생산 사이트 측면에서는 큰 문제가되지 않습니다.

개별 버전 스크립트를 유지하면 IMHO는 배포에 적합 할뿐만 아니라 소스 컨트롤에 체크인 할 수있는 항목을 제공하는 데 좋습니다.

Answer 2

많은 프레임 워크는 "마이그레이션"이라는 개념을 사용합니다. 데이터베이스 스키마를 한 개정판에서 다음 개정판으로 업그레이드하는 스크립트. 마찬가지로, 다운 그레이드 스크립트는 일반적으로 변경을 철회 해야하는 경우에도 유용합니다. 때때로이 스크립트는 SQL에 있으며 때로는 추상화됩니다 (예 : Ruby on Rails). 이 스크립트를 직접 설계하거나 다른 스크립트가 언급 한 SQL 비교와 같은 도구를 사용할 수 있습니다.

또한 스키마 개정을 표시하기 위해 하나의 열 (한 열)으로 데이터베이스에 테이블을 만드는 것이 도움이됩니다. 마이그레이션을 지원하는 일부 프레임 워크는 이에 의존하여 스키마 업그레이드 또는 다운 그레이드에 적용 할 마이그레이션 스크립트를 알기 위해 의존합니다.

애플리케이션에는 응용 프로그램 기능을 검증하기 위해 실행할 수있는 다양한 테스트 제품군이 있어야합니다. 또한 스키마를 검사하고 예상 테이블, 열, 절차 등을 확인하는이 제품군에 기능 테스트를 추가 할 수도 있습니다. 프로젝트를 수정하면 테스트를 수정하십시오. 응용 프로그램 기능 테스트가 테스트 된 코드와 함께 소스 컨트롤에서 추적 해야하는 것처럼 스키마 구조 테스트를 추적해야합니다.

마지막으로 데이터베이스 설계는 응용 프로그램 설계의 기초를 형성합니다. 적절한 소프트웨어 엔지니어링은 배포하기 전에 비교적 안정적인 데이터베이스 스키마를 초래해야합니다. 데이터베이스 스키마에 대한 후속 변경은 작고 드물게되어야합니다.

Answer 3

첫째, 스키마가 설정된 응용 프로그램의 버전 번호를 추적하는 스키마 버전 테이블을 소개하고 각 Invidual 테이블의 정점을 추적합니다. 이 애플리케이션 버전에 대해 확인하기 위해 응용 프로그램에 하드 코드가 스키마 버전이 있습니다. 우리는 응용 프로그램이 DB의 잘못된 버전에 액세스하는 것을 원하지 않습니다. 그런 다음 각 테이블에 대한 스크립트 세트가 이전 테이블 버전에서 현재 버전으로 마이그레이션됩니다. 그런 다음 응용 프로그램에 포함시킨 대상 테이블이 새 버전의 각 테이블의 버전을 알기 위해 각 테이블의 모든 버전을 알 수 있습니다. 그렇지 않은 경우 다양한 마이그레이션 스크립트를 스키마에 적용하여 DB를 스노프까지 올리십시오.

복잡한? 약간. 생명 구원. 욕설. 스키마가 잘못 되었기 때문에 앱에서 오류를 쫓는 것과 같은 것은 없습니다.

Answer 4

PowerDesigner라는 도구를 살펴 봐야합니다. 15 일간의 완전 운영 시험을 다운로드 할 수 있습니다. 모델을 모델링하고 최신 변경 등을 유지하는 데 도움이됩니다.

그것은 당신이 요구하는 일과 훨씬 더 많은 것을위한 훌륭한 도구입니다.

Answer 5

우리는 버전 제어 저장소 내에 각 릴리스에 대한 디렉터리를 만듭니다.해당 폴더의 스크립트를 읽고 파일 이름 순서로 실행하는 스크립트를 작성했습니다(그래서 32.0.0_AddColumnXxxxYyyy와 같은 이름으로 스크립트를 작성했습니다).이 점 형식을 사용하면 필요에 따라 시퀀스에 스크립트를 삽입할 수 있습니다.

사이트를 업데이트하면 새 스크립트가 감지되어 실행됩니다.이는 데이터를 한 번만 수정할 수 있기 때문에 SQL 비교(내가 정말 좋아하는)와 같은 도구에 비해 이점이 있습니다.그러나 우리는 SQL Compare와 SQL Data Compare를 실행합니다(선택한 테이블에 대해). ~ 후에 절차가 제대로 작동하는지 확인하기 위해 업데이트합니다.성공적으로 실행되면 전체 작업이 커밋되고 데이터베이스는 "스크립트 실행" 정보를 업데이트하여 이러한 스크립트가 다시 실행되지 않도록 합니다.

이 방법의 좋은 점은 스크립트를 "잊을" 수 없다는 것입니다.또한 테스트 또는 준비 데이터베이스로 롤백하려고 할 때 대체 데이터 세트가 프로덕션에 도달하기 전에 찾아낸다는 숨겨진 가정을 종종 발견합니다.

또 다른 이점은 다양한 고객을 위해 다양한 기능 수준에서 다양한 설치를 유지할 수 있지만 업그레이드할 때 모든 스크립트가 제자리에 있고 실행할 준비가 되어 있다는 것입니다.이 구성표에서 내가 겪은 유일한 문제는 사용자 데이터베이스에 적용되는 "순서가 잘못된" 패치입니다...원래 상태를 감지하려면 스크립트를 작성해야 합니다. 예상대로 그렇지 않은 경우 중단합니다.

Answer 6

Atwood가 코딩 공포에 대한 DB 버전 컨트롤에 대해 쓴 Aticle을 읽어야 할 것입니다. 데이터베이스가 버전을 제어하고 있습니까?

Answer 7

XSQL 소프트웨어의 Redgate의 SQLCompare 또는 XSQL 객체와 같은 도구를 사용하여 DIFF/DELTA T-SQL 스크립트를 즉시 생성하십시오.

원하는 경우 빌드 프로세스의 일부로 통합 할 수도 있습니다.

데이터베이스가 다른 다른 고객의 경우 비교할 수있는 다른 참조 데이터베이스가 있습니다. 고객에게 업데이트를 해제하면 동일한 DIFF 스크립트로 자신의 참조 사이트를 업데이트합니다.

그게 간단히 말해.

Answer 8

나는 당신과 거의 같은 방식으로 그것을합니다. 전복 개정 번호가 표시된 상단에 가장 최근의 변경 사항이있는 데이터베이스 릴리스 노트 파일을 보관합니다. 또한이 변경 사항을 적용하기 위해 실행 된 SQL도 포함되어 있습니다.

동시에 데이터베이스 모델을 유지 관리합니다 (사용합니다. Azzurri 점토 Eclipse)에서 언제든지 모델을 재생할 수 있습니다. 필요한 변경 사항은 먼저 모델을 작성한 다음 릴리스 노트를 업데이트합니다. azzurri는 만 생성하지만 변경을 생성 할 수는 없습니다.

필요할 때 롤백 할 수 있도록 모두 전복하에 저장됩니다. 아마도 내 앱의 SVN 개정과 모델의 개정 사이에 어떤 종류의 링크를 유지해야합니다.