새 버전을 푸시 할 때 데이터베이스 스키마 변경 처리

17

많은 개발이 진행되는 동안 데이터베이스 스키마는 빠르고 지속적으로 변경되며, 매주 베타 빌드에 대한 푸시가 진행될 때마다 스키마가 너무 많이 변경되어 가능한 모든 테이블을 정리할 수 있습니다. dev 데이터베이스에서 새 버전을 복사하십시오. 프로덕션 데이터를 핵 공격하는 것은 재난을위한 레시피이기 때문에 출시 후에는 작동하지 않을 것입니다. 따라서 한 버전 / 개정에서 다른 버전으로 데이터베이스 스키마 변경을 관리하기 위해 어떤 전략이 있는지 궁금했습니다.

내가 찾거나 경험 한 일부 :

한 데이터베이스에서 다른 데이터베이스로 바로 핵 폐기 (내가 지금하고있는 것)
스크립트를 통해 또는 수동으로 실행되는 SQL 문으로 UPDATE.sql 파일 유지 보수
활성 데이터베이스에서 해당 "db-schema-version"값으로 update.php 파일 유지

세 번째 옵션은 가장 현명한 것으로 보이지만 잘못 구성된 SQL 쿼리가 스크립트 중간에 실패하여 데이터베이스를 절반 업데이트 된 상태로 유지하여 백업을 복원해야 할 가능성이 여전히 있습니다.

문제가 아닌 것처럼 보이지만 팀이 phpMyAdmin을 사용하기 때문에 발생합니다. 실행 된 SQL 문을 복사하여 update.php 파일에 붙여 넣는 것을 기억하는 것조차 나 자신에 의존 할 수 없습니다. 다른 페이지로 이동하면 SQL 문을 직접 다시 작성하거나 변경 사항을 되돌리고 다시 수행해야합니다.

기존의 개발 워크 플로에 영향을 미치지 않는 솔루션이라고 생각합니다.

database versioning push

— 줄리안 H. 램
소스

그러나 물론 테스트 환경에서 파일 update.php또는 update.sql파일을 테스트하여 활성 데이터베이스에 적용해야합니까? 그리고 PHPMyAdmin은 스크립트와 같이 발생할 수있는 문제로 인해 비난을 받고 있습니다.

— FrustratedWithFormsDesigner

하하, 네가 날 잡았어 나는 처음부터 문제를 해결하는 대신 내 자신의 실패를 해결하려고합니다.

— Julian H. Lam

이 작업을 수행했다면 예제 스크립트를 보여 주시겠습니까? 나도 이것을하려고 노력하고 있지만 MS SQL 간 MySql을 번역하는 방법을 모르겠습니다 : stackoverflow.com/questions/26948916/…

— Richard

우리는 같은 문제에 직면하여 도구를 작성했습니다. 각 업그레이드는 숫자 식별자가있는 파일 (낮은 수에서 높은 수로 파일 실행)이며 실제 DB를 릴리스하기 전에 테스트 DB와 비교하여 각 파일을 확인하고 어떤 파일이 릴리스되었는지에 대한 레코드를 저장합니다. 물론, 그것은 모두 자동화되어 주 관계 시스템에 연결되어 있습니다.

— Itay Moav-말리 모프 카

11

자동화 자동화 자동화

명시 적 DB 버전 번호로 올바른 길을 가고 있지만 한 걸음 더 나아가 코드가 정확히 어떤 스키마에 대해 작동하는지 정확히 인식하도록합니다 (예 : 실제 DDL 스크립트를 커밋하고 업데이터가 파싱하도록) ); 그런 다음 업데이트시 어떤 버전에서 어떤 버전으로 업데이트하든 관계없이 데이터베이스 메타 데이터 및 INSERT / DROP / ALTER를 통해 기존 구성표 만 검색하면됩니다. (또한 데이터베이스 자체에 명시적인 버전 번호를 유지하고 스키마 검색이 필요하지 않도록 설치 프로그램으로 전체 스키마 기록을 제공 할 수 있습니다.)

SQL 업데이트 스크립트의 잠재적 구문 오류는 문제이지만 업데이터가 올바른 DDL 문만 생성 할 수 있는지 확인하여 해결할 수 있습니다. (공식 증명은 엔터프라이즈 소프트웨어 개발에서 거의 가치가 없습니다. 너무 적은 노력으로 너무 많은 노력을 기울입니다.) 데이터베이스 무결성은 몇 가지 예외 중 하나라고 생각합니다. 기본 SQL은 공식적으로 캡처하기에 특히 어려운 언어는 아니며 프로덕션 데이터를 보호하는 것이 매우 뛰어나 특히 무인 설치에 필요한 경우 거의 모든 일회성 선행 작업이 정당화됩니다.)

— 킬리안 포스
소스

훌륭한 조언 Kilian, 감사합니다. 나는 결국 이것을 자동화하기를 바랐지만 어느 시점에서 UPDATE / ALTER 문을 생성하는 데 여전히 인간의 개입이 필요한 것 같습니다.

— Julian H. Lam

2

데이터베이스 스키마 버저 닝은 갈 길입니다-각 버전은 데이터베이스를 한 번만 변경하거나 최소한 전체적으로 되돌릴 수있는 변경 사항을 갖습니다. DBDeploy 는이를 자동화하는 훌륭한 도구입니다.

내가 배운 유용한 것들은 다음과 같습니다.

항상 로컬 변경 사항을 테스트하고 그것으로 코드를 테스트, 그냥 ALTER통과는 충분하지 않습니다
먼저 변경을 수행 할 동기화를 수행해야합니다. 팀에 "수를 가져갈 수있는"간단한 위키 페이지가 있습니다.
깨진 변화를 고치려고하지 말고, 새로운 반 변화를 추가하여 무효화하십시오.
코드는 변경 사항에 따라 다릅니다. 버그 추적 시스템의 문제를 DB 변경 사항과 연결해야합니다. 배포시 매우 유용합니다.
CI에 DB 변경 사항 포함-커밋시 CI 데이터베이스에 변경 사항을 적용합니다. 또한 데이터베이스를 사용하는 테스트가 있으면 커밋시 실행하십시오.

— jmruc
소스

도움을 주셔서 감사합니다 :)

— jmruc

0

phpMyAdmin을 사용하고 있으므로 MySQL도 사용한다고 가정합니다.

MySQL Workbench의 EER 모델 다이어그램을 살펴보십시오. 스키마를 유지 관리하고 업데이트하는 데 큰 도움이되었습니다.

먼저 모델을 데이터베이스 소스와 동기화 할 수 있습니다. 따라서 다이어그램의 변경 사항은 ALTER TABLE 명령으로 푸시됩니다. 이를 통해 다이어그램에서 스키마 변경을 수행하고 필요한 경우 개발 데이터베이스에 대한 업데이트를 제공하면서 항상 최신 상태로 유지할 수 있습니다.

둘째, 데이터베이스 소스에서 EER 다이어그램을 리버스 엔지니어링 할 수 있습니다. 개발 데이터베이스를 변경하고 차이를 계산하므로 프로덕션 데이터베이스를 업데이트하면 편리합니다.

셋째, "update.sql"파일로 들어가야하는 SQL 작성을 지원하는 데 사용할 수 있습니다.

단점 :

데이터베이스 트리거 및 제약 조건은 동기화 업데이트 프로그램의 문제입니다. 올바른 순서를 모르는 것 같습니다. 외래 키 제약 조건은 종종 오류를 생성하지만 생성 된 SQL을 편집하여 해결할 수 있습니다.

이것은 데이터 마이그레이션 도구가 아닙니다. 순전히 스키마를 벗어난 변경 사항에는 여전히 사용자 지정 SQL이 필요합니다.

— 반응
소스

0

http://south.aeracode.org를 살펴보십시오. Django (Python 프레임 워크) 용 DB 마이그레이션 라이브러리이지만 다음과 같습니다.

당신은 그것으로부터 좋은 아이디어를 얻을 수 있습니다 (아마도 PHP 클론을 찾을 수 있습니다)
실제로 Django의 나머지 부분과 독립적으로 사용하여 PHP / MySQL 앱의 테이블을 관리 할 수 있습니다.

스키마 업데이트 스크립트를 생성 할 수도 있습니다. 또한 대부분의 경우 자동으로 변경 취소를 처리합니다.

— 에릭 카플 룬
소스

슬프게도, 그들은 그것을 장고 코어의 일부로 만들었고 더 이상 혼자 서 있지 않았다

— Itay Moav -Malimovka