(SQL Server) 데이터베이스를 업데이트하기위한 단계별 지침?

Question

기존 데이터베이스를 업그레이드 할 때 가장 좋은 방법에 대한 질문입니다. 데이터 자체, 구조, 관계, 추가 열, 사라지는 열 등 모든 종류의 수정이있을 것이라고 가정합니다.

내 문제는 간단합니다. 나는 SQL Server를 사용할 프로젝트에서 일하고 있습니다. 문제는 없습니다. 전문가를 충분히 처리 할 수 ​​있기 때문입니다. 하지만이 프로젝트는 나중에 업그레이드 될 것이므로 업그레이드 메커니즘이 뒤따라야하는 프로토콜을 지정해야합니다. 기본적으로,이 프로토콜은 업그레이드 스크립트를 생성 할 때 따라야 할 필요가 ...

는 지금, 나는 다음의 간단한 단계가 있습니다

1. 이 테이블에 새 열을 추가합니다.
2. 새 열에 제약 조건을 추가하십시오.
3. 새 테이블을 추가하십시오.
4. 필요한 경우 제약 조건을 삭제하십시오.
5. 제거해야 할 열을 버립니다.
6. 제거해야하는 삭제 테이블.

어떻게 든이 목록은 불완전하다고 느낍니다. 업그레이드 중에 따라야 할 적절한 단계를 설명하는 확장 목록이 있습니까?

또한 단일 데이터베이스 트랜잭션 (SQL Server 사용) 내에서 항상 전체 업그레이드를 수행 할 수 있습니까? 아니면 하나의 트랜잭션을 종료하고 다른 트랜잭션을 시작해야하는 프로토콜 내에 포함되어야하는 중단 점이 있습니까?

---

자동화 된 도구는 멋진 자동 솔루션을 제공하지만 실제로 사용할 수는 없습니다. 이 시스템에서 작업하는 개발 팀은 로컬 시스템에 자체 데이터베이스가있는 4 명의 개발자가 있습니다. 모든 개발자는 구조 변경 및 데이터 변경에 대한 자체 수정을 위해 업그레이드 및 다운 그레이드 스크립트를 생성하여 구조에 대한 자체 업데이트를 추적하고 추적합니다. 이 스크립트는 다른 개발자가 자신의 시스템을 최신 상태로 유지하는 데 사용할 수 있습니다. 시스템이 출시 될 때마다 스크립트는 모두 하나의 큰 스크립트로 병합됩니다.

시스템은 이 아니며은 저장 프로 시저 또는 기타 "특수"기능을 포함합니다. 데이터베이스는 테이블과 관계가있는 데이터 저장소입니다. 역할 없음, 사용자 없음, 저장 프로 시저 없음, 트리거 없음, 복잡한 데이터 유형 없음 ...

---

사용자가 9에서 5로 작업하는 응용 프로그램에서 DB를 사용하므로 클라이언트 업그레이드를 포함하여 종료를 쉽게 수행 할 수 있습니다. 또한 데이터베이스에 버전 번호를 추가하면 응용 프로그램이 올바른 데이터베이스 버전에 연결되어 있는지 확인합니다.

개발하는 동안 모든 개발자는 완전히 제어 할 수있는 자체 데이터베이스 인스턴스를 사용합니다. 우리는 응용 프로그램을 사용하는 사용자가 아니기 때문에 더 이상 비싼 에디션이 아닌 Express 에디션 용으로 개발하는 경향이 있습니다. 솔직히 우리는 많은 사용자를 지원하는 응용 프로그램을 개발하지 않지만 사용자가 SQL Server를 사용하기 때문에 자신의 필요에 따라 더 큰 SQL Server 플랫폼에 시스템을 설치할 수 있음을 알립니다. 그들은 자신의 DBA가 필요합니다. 우리는 우리 자신의 웹 인터페이스에 사용되는 더 큰 SQL Server를 사용할 수 있지만이 서버는 우리가 아닌 우리를 위해 유지 관리되는 특별한 dataserver에 있습니다.

이 프로젝트는 이전에 MS Access를 데이터 저장소로 사용하고 단일 사용자 개발 용 이었지만 많은 사용자들이 여전히 데이터베이스를 공유하기로 결정했기 때문에 데이터 모델 자체가 멀티 - 사용자 환경. 그래서 우리는 SQL Server로 마이그레이션하여 3 명 이상의 사용자가있는 소규모 사무실과 동시에 500 명 이상의 사용자가있는 대규모 조직을 지원했습니다.

우리는 소프트웨어 비용을 낮게 유지해야하기 때문에 값 비싼 도구 나 비싼 서버에 많은 예산을 쓸 필요가 없습니다.

Answer 1

Red-Gate의 SQL Compare (구조 비교), SQL Data Compare (데이터 비교) 및 SQL Packager (업데이트 스크립트를 C# 프로젝트 또는 .NET 실행 파일로 패키징)을 확인하십시오.

그들은 데이터베이스 업그레이드에 필요한 모든 기능을 제공하는 완벽하고 기능이 뛰어나고 사용하기 쉬운 솔루션을 제공합니다. 라이센스 비용은 그 가치가 충분합니다. 이는 몇 주 또는 몇 달 만에 비용을 지불합니다.

강력 추천!

Answer 2

내 견해로는 절대적으로이를 수동으로 수행하는 것입니다. Microsoft SQL Server의 경우 Team System의 데이터베이스 편집 기능을 사용하는 것이 좋습니다. 데이터베이스에 대한 완전한 소스 제어 기능이 포함되어 있으며 버전 업그레이드/다운 그레이드를위한 스크립트를 자동으로 빌드 할 수 있기 때문입니다.

또 다른 옵션으로는 이러한 종류의 업그레이드/다운 그레이드를 처리 할 수있는 Redgate의 SQLCompare가 있으며 매우 훌륭한 SQL 스크립트가됩니다. 둘 다 사용했고 역사적인 스크립트를 유지하면 문제를 해결하고 많은 미스터리를 해결하는 데 도움이되었습니다.

위와 같이 수동 스크립트로 작업하는 경우 스크립트에서 SP 변경 사항도 고려해야합니다. 또한 수작업으로 편집 된 스크립트는 데이터베이스에서 여러 번 실행할 수 있어야합니다. 즉, 스크립트에 표 생성 또는 삭제가 포함 된 경우 먼저 존재 여부를 확인해야합니다. 그렇지 않으면 연속적으로 실행하면 스크립트가 실패합니다.

수동 프로토콜을 구축 할 수는 있지만 의도 한 도구 중 하나를 사용하여 다시 폴링 할 수 있으며 Team System과 SQL Compare는 다음과 같이 포함시킬 수있는 스크립트를 출력 할 수 있습니다. 설치/업그레이드 패키지의 일부

Answer 3

데이터베이스 업데이트를 통해 나는 항상 그것이 전부 또는 아닌 것으로 믿습니다. DB 업데이트 중 하나라도 실패하면 응용 프로그램이 데이터에 해를 끼칠 수있는 알 수없는 상태로 남게되므로 모두 적용하거나 모두 적용하지 않는 것이 가장 좋습니다.

아무 것도 잘못되면 데이터베이스가 롤백 될 수 있도록 업데이트를 적용하기 전에 데이터베이스를 백업하는 것이 좋습니다 (실제 데이터로 작업 할 때 여러 번 저를 저장했습니다).

희망이 도움이됩니다.

Answer 4

프로덕션 데이터베이스 스키마 업그레이드에 대한 우수 사례는 실제로 표면적으로보기에는 매우 좋지 않습니다. 업그레이드를 위해 시스템을 완전히 종료 할 수없는 경우가 아니라면 (일반적으로 가능하지 않은 경우) 이전 버전과의 호환성을 모두 유지해야합니다. 데이터베이스에 액세스하는 많은 클라이언트가있는 경우 이들을 동시에 모두 업데이트 할 수 없으므로 스키마를 변경하면 이전 코드를 실행할 수 있어야합니다.

즉, 열의 이름을 바꾸지 않고 모든 새 열을 null로 지정할 수 있습니다. 그렇다고해서 영원히 남겨 둘 수는 없습니다.두 개의 스크립트를 작성합니다. 하나는 초기 변경을위한 스크립트이고 다른 하나는 역 호환이되는 스크립트이고 다른 하나는 모든 클라이언트가 업데이트 된 후 정리하는 스크립트입니다.

자동화 된 도구는 스키마의 유효성 검사에 적합하지만 실제로 복잡한 시스템을 수정하는 경우에는 그리 좋지 않습니다. 변경 사항을 작은 개별 스크립트로 분할해야 각 스크립트를 수동으로 실행할 수 있습니다. 오류가있는 경우 원인을 찾아 수정하는 것이 더 쉽습니다. 기본적으로 각 기능에는 자체 스크립트가 있습니다. 각각의 고유 한 이름을 부여한 다음 스크립트를 실행할 때 해당 이름을 데이터베이스 자체에 저장하면 데이터베이스를 쿼리하여 실행 된 항목과 실행되지 않은 항목을 찾을 수 있습니다. 개발자의 컴퓨터, 테스트 서버, 프로덕션 등에 인스턴스가있는 경우 매우 유용합니다.