역 호환 데이터베이스 변경

Question

DBA와 데이터베이스 스키마 변경 방법에 대해 논의했습니다. 그의 의견은 모든 변화가 되돌릴 수 있어야한다는 것이다. 예 :

• 더 이상 사용되지 않는 테이블/열은 중복되는 즉시 삭제할 수 없습니다. 대신 적어도 몇 가지 릴리스에 보관해야합니다.
• 테이블/열의 이름을 바꾸는 대신 새 테이블/열을 만들고 이전의 내용을 새 것으로 복사하십시오
• 'foo'라는 저장된 proc/trigger를 수정해야 할 경우 원래 저장된 proc/장소에서 트리거하고 'foo2'라는 새 저장된 proc/trigger를 만듭니다. 물론 이것은 저장된 proc/trigger에 대한 모든 참조가 새 이름을 참조하도록 업데이트되어야 함을 의미합니다.

이 접근법의 이점은 데이터베이스가 이전 버전으로 전환 될 수 있다는 것입니다. 릴리스가 실패하고 이전 버전의 응용 프로그램으로 되돌려 야합니다. 테이블과 열을 단순히 삭제하면이 작업은 불가능합니다.

나는이 접근법의 지혜에 관해 나 자신의 견해를 가지고 있지만, 응답을 편향시킬 것을 두려워 당분간은 나 자신에게 맡길 것이다. 차이가 나는 경우, 환경은 소셜 네트워크 앱을 개발하는 신생 기업입니다.

Answer 1

당신이 어떤 소프트웨어 환경에 있지만 당신은 엔터프라이즈 (뱅킹) 업무에서 내 의견을 말하지 않습니다.

일반적인 원칙은 올바른 SQL 코드가 아니라 클라이언트 코드로 인해 서버에서 되돌릴 수 있어야합니다. 나는 이것이 여러 번 일어나는 것을 보았다.

출시 후 몇 시간 후에 문제가 발견되면 그 동안 입력 한 모든 데이터를 처리해야합니다.

릴리스 시간에 가져온 데이터베이스의 복제본을 새로운 데이터로 업데이트 할 수 있지만 환경에서 허용하지 않을 수 있습니다 (대용량 배포를 수행 한 주된 방법 임).

제 경험상 릴리스 문제는 시스템의 작은 부분에 영향을 줄 수 있으며 대부분은 정상이므로 작은 부분을 복구하기 위해 전체 시스템을 종료하고 되돌리려는 것을 원하지 않습니다.

그러나 변경 사항을 되돌릴 필요가 있다고 생각하면 dba는 다소 보수적 인 것으로 생각됩니다.

테이블과 열은 어떤 단계에서 감소해야하지만 아마도 가장 이름이 완전히되지 않는로 이름을 변경하지 다시

예를 되돌릴 수 있도록 이후 릴리스 때까지 기다려야 항상 사실 (데이터를 복사 할 수 있습니다 변화를 일으킬 위험을 감수해야한다. 열의 유형을 변경해야하는 경우 SQL Server 및 수행중인 작업에 따라 다 (니다. Sybase에서는 데이터를 변경하지 않지만 열의 크기를 줄이면 데이터 값이 영향을받을 수 있으므로 복사본이 필요하므로 필자는 Sybase의 경우 열의 크기를 늘릴 수 있습니다.

저장 프로 시저 및 트리거의 경우 이름을 바꾸지 않고 컴파일 된 코드와 같이 덮어 쓸 것입니다. 변경중인 오브젝트는 데이터에 의존하지 않으므로 즉시 재 작성 될 수 있습니다. 이것은 버전 관리 등에서 스토어드 프로 시저의 이전 버전을 쉽게 얻을 수 있다고 가정합니다.(코드가 버전 제어하에 있지 않고 유일한 버전이 db에 있고 코드를 덮어 쓸 필요가 없다는 것을 알았지 만 다음 릴리스 전에 제어 코드를 얻을 수 있습니다)

Answer 2

DBA가 백업을하기에는 너무 게으른 것처럼 들립니다. ;)

Answer 3

나는 항상 데이터베이스의 백업을 만들어야한다는 것에 동의하지만 쓸모없는 정보로 데이터베이스를 오염시키지 않아야한다. 코드를 쓸모없는 코드로 오염시키지 말아야하는 것과 동일합니다.

데이터베이스를 백업 한 다음 모델을 만드십시오. 문제가 발생하면 백업으로 되돌립니다.

항상 데이터베이스에 모든 것을 보관하면 믿을 수 없을만큼 부풀어 오릅니다.뿐만 아니라 성능 문제가 발생할 수 있습니다. 그리고 가장 중요한 것은 나중에 왜 그곳에 있는지 알 수 없으므로 아무도 나중에 만지기를 원할 것입니다. 코드와 달리 미래의 날짜에 데이터베이스에 추가 열이있는 이유를 파악하는 것이 더 어렵습니다. 그들은 기존의 데이터/코드라는 것을 알지 못하기 때문에 유지 관리 만 할 것입니다!

Answer 4

"더 이상 사용되지 않는 테이블/열은 중복되는 즉시 삭제할 수 없으며 최소한 몇 개의 릴리스에 보관해야합니다."

그는 또한 즉시 삭제하려고하지 않는 열을 관리하는 제약 조건을 유지합니까?

사용자가 선언 한 제약 조건이 더 이상 비즈니스 규칙의 일부가 아니기 때문에 업데이트 실패가 발생할 수 있음을 의미합니까?

나는 점차적으로 그리고 조심스럽게 단계적으로 퇴보하려는 사람들에게 동정심이 많습니다. 나는 당신이 언급 한 모든 예에서 데이터베이스 접근법에서 그 접근법을 고수 할 수 있는지 여부를 모른다.