데이터베이스 개체를 다른 스키마로 이동
데이터베이스 개체를 다른 스키마로 이동할 때 데이터베이스 리팩터링을 사용하면 데이터베이스 프로젝트에서 해당 개체에 대한 모든 참조를 보다 쉽고 정확하게 업데이트할 수 있습니다. 예를 들어 보안을 향상시키거나 데이터베이스를 보다 논리적으로 구성하기 위한 목적 등으로 데이터베이스를 여러 개의 스키마로 분할할 수 있습니다. 이러한 분할 후에는 하나 이상의 개체를 새 스키마로 이동할 뿐 아니라 해당 개체에 대한 모든 정규화된 참조를 업데이트해야 합니다. 모든 참조가 새 스키마를 참조하도록 수동으로 변경하면 오류가 발생할 수 있습니다. 데이터베이스 리팩터링을 사용하면 해당 참조를 자동으로 찾고 업데이트할 수 있습니다.
리팩터링 로그를 사용하여 변경 의도 보존
데이터베이스 개체를 다른 스키마로 이동하면 데이터베이스 프로젝트의 리팩터링 로그에 항목이 추가됩니다. 변경 내용을 배포할 때 이 로그를 사용하면 대상 환경에서 해당되는 개체가 의도한 대로 이름이 바뀌도록 할 수 있습니다. 그러지 않으면 기존 개체가 삭제되고 새 이름의 개체가 추가됩니다. 이 로그는 ProjectName.refactorlog라는 XML 파일에 보관됩니다. 데이터베이스 프로젝트를 구성하는 다른 파일을 버전 제어에 체크 인할 때 이 파일도 체크 인해야 합니다. 하지만 ProjectName.refactorlog 파일에는 배포 중 특수한 처리가 필요한 리팩터링 작업에 대한 정보만 포함됩니다.
배포
리팩터링을 사용할 때는 프로덕션 데이터베이스 대신 데이터베이스 프로젝트만 업데이트합니다. 이 전략을 따르면 버전 제어와 팀 개발을 비롯하여 데이터베이스 프로젝트의 모든 이점을 얻을 수 있습니다. 변경 내용을 배포할 경우 리팩터링 로그를 사용하여 데이터베이스 프로젝트의 변경 의도를 보존할 수 있습니다. 예를 들어 DROP 및 ADD 작업 대신 이름 바꾸기를 수행할 수 있습니다.
자세한 내용은 데이터베이스를 빌드하여 격리된 개발 환경에 배포를 참조하십시오.
참고
팀 환경에서는 변경 내용을 프로덕션 서버에 배포하기 전에 응용 프로그램 및 데이터베이스 단위 테스트를 실행해야 합니다. 자세한 내용은 팀 데이터베이스 개발 시작을 참조하십시오.
일반 작업
다음 표에서는 이 시나리오를 지원하는 일반적인 작업에 대한 설명과 해당 작업을 성공적으로 완료하는 방법에 대한 자세한 내용을 볼 수 있는 링크를 보여 줍니다.
Task |
지원 항목 |
|---|---|
실습: 연습 과정을 따라 다른 형식의 리팩터링 외에도 데이터베이스 개체를 다른 스키마로 이동하는 방법을 익힐 수 있습니다. |
|
데이터베이스 개체를 다른 스키마로 이동: 리팩터링을 사용하여 데이터베이스 개체를 다른 스키마로 이동하고 데이터베이스 프로젝트에서 해당 개체에 대한 모든 참조를 자동으로 업데이트할 수 있습니다. 리팩터링 작업의 일부로 변경 내용을 적용하기 전에 미리 볼 수 있습니다. |
|
리팩터링 작업 실행 취소: 리팩터링 작업을 되돌려야 하는 경우 Visual Studio의 현재 세션에서 해당 리팩터링 작업의 실행을 취소할 수 있습니다. |
|
데이터베이스 리팩터링 변경 내용 배포: 데이터베이스 프로젝트를 리팩터링한 후에는 해당 변경 내용을 대상 데이터베이스에 배포해야 합니다. 일반적으로 변경 내용을 버전 제어에 체크 인하기 전에 격리된 개발 환경에 배포하여 테스트합니다. |
|
문제 해결: 데이터베이스 리팩터링과 관련된 일반적인 문제를 해결하는 방법에 대해 알아보십시오. |