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

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

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

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

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



답변

버전 관리에서 데이터베이스 가져 오기를 읽어야 합니다 . 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로 이루어 졌다고 생각합니다.