데이터베이스 개체에 대한 모든 참조 이름 바꾸기
데이터베이스 리팩터링을 사용하면 이름이 바뀐 데이터베이스 개체에 대한 참조를 보다 빠르고 정확하게 업데이트할 수 있습니다. 데이터베이스 프로젝트에 포함된 데이터베이스 개체의 이름을 바꿀 경우 개체를 새 이름으로 참조할 수 있도록 해당 개체에 대한 모든 참조도 업데이트해야 합니다. 예를 들어 이름을 바꾼 테이블 열을 참조하는 모든 저장 프로시저를 업데이트해야 합니다.
리팩터링을 사용하면 다른 개체를 참조하는 개체를 수동으로 추적한 다음 한 번에 하나씩 참조를 업데이트하지 않고도 데이터베이스 프로젝트 전체의 참조를 업데이트할 수 있습니다. sp_depends를 사용하여 종속 개체를 찾더라도 해당 정보가 항상 정확하게 검색되지는 않으며 여전히 각 참조를 업데이트해야 합니다.
리팩터링을 사용하여 다음 형식의 개체 이름을 자동으로 바꿀 수 있습니다.
테이블
테이블의 열, 뷰 및 함수
저장 프로시저 매개 변수
리팩터링을 사용하여 데이터 생성 계획, 스크립트 및 단위 테스트를 업데이트할 수도 있습니다. 자세한 내용은 데이터베이스 개체의 이름을 바꾸기 전 고려 사항을 참조하십시오.
기본적으로 정의로 인해 하나 이상의 경고나 오류가 발생하는 개체는 리팩터링 시 업데이트되지 않습니다. 또한 이름을 바꾼 개체에 대한 정의가 들어 있는 .sql 파일의 이름도 리팩터링 시 자동으로 업데이트되지 않습니다. 이 파일의 이름은 솔루션 탐색기에서 수동으로 바꿀 수 있습니다.
이름 바꾸기 리팩터링의 추가적인 사용 방법
이름 바꾸기 리팩터링을 사용하여 다음과 같은 일반적인 작업을 수행할 수도 있습니다.
대/소문자를 구분하지 않는 환경에서 개체 이름과 모든 해당 참조의 대/소문자를 조직의 대/소문자 규칙에 맞도록 변경할 수 있습니다. 예를 들어 데이터베이스 프로젝트에 "Myid" 및 "MyID"에 대한 참조가 혼합되어 있는 경우 이름 바꾸기 리팩터링을 사용하여 모든 참조를 "MyID"로 변경할 수 있습니다.
참고
대/소문자가 올바른 참조도 동일한 값으로 업데이트됩니다. 해당 참조가 들어 있는 파일이 버전 제어에서 관리되는 경우 이 파일은 리팩터링 작업의 일부로 체크 아웃됩니다.
이름과 참조가 일치하도록 두 개 이상의 개체 이름을 바꿀 수 있습니다. 예를 들어 "Person" 및 "Person Name"과 같은 두 개의 스키마 이름을 병합할 수 있습니다. 대/소문자를 구분하는 환경에서 "MyID"와d "Myid" 같이 대/소문자 형식만 다른 두 개의 이름을 병합할 수도 있습니다.
개체 명명에 대한 모범 사례를 따르기 위해 스키마 개체 이름과 모든 해당 참조의 앞뒤에 대괄호를 추가할 수 있습니다. 예를 들어 "MyID"에 대한 모든 참조를 "[MyID]"로 바꿀 수 있습니다.
참고
이미 대괄호로 묶여 있는 참조도 동일한 값으로 업데이트됩니다. 해당 참조가 들어 있는 파일이 버전 제어에서 관리되는 경우 이 파일은 리팩터링 작업의 일부로 체크 아웃됩니다.
이러한 작업을 수행하면 해당 이름을 가진 개체가 이미 있다고 경고하는 오류 메시지가 표시됩니다. 변경 내용을 적용하려면 예를 클릭해야 합니다. 그러나 이름 바꾸기 대화 상자에서 변경 내용 미리 보기 확인란을 선택된 상태로 두면 개별 변경 내용을 미리 보고 원하지 않는 내용을 제외할 수 있습니다.
리팩터링 로그를 사용하여 변경 의도 보존
데이터베이스 개체의 이름을 바꾸면 데이터베이스 프로젝트의 리팩터링 로그에 항목이 추가됩니다. 변경 내용을 배포할 때 이 로그를 사용하면 대상 환경에서 해당되는 개체가 의도한 대로 이름이 바뀌도록 할 수 있습니다. 그러지 않으면 기존 개체가 삭제되고 새 이름의 개체가 추가됩니다. 이 로그는 ProjectName.refactorlog라는 XML 파일에 보관됩니다. 데이터베이스 프로젝트를 구성하는 다른 파일을 버전 제어 시스템에 체크 인할 때 이 파일도 체크 인해야 합니다. 하지만 ProjectName.refactorlog 파일에는 배포 중 특수한 처리가 필요한 리팩터링 작업에 대한 정보만 포함됩니다.
배포
리팩터링을 사용할 때는 프로덕션 데이터베이스 대신 데이터베이스 프로젝트만 업데이트합니다. 이 전략을 따르면 버전 제어와 팀 개발을 비롯하여 데이터베이스 프로젝트의 모든 이점을 얻을 수 있습니다. 데이터베이스 프로젝트를 빌드하면 모든 리팩터링 로그 파일이 프로젝트의 \sql 폴더에 transaction.refactorlog 파일로 병합됩니다. 변경 내용을 배포할 경우 이 병합된 리팩터링 로그 파일을 사용하여 데이터베이스 프로젝트의 변경 의도를 보존할 수 있습니다.
자세한 내용은 데이터베이스를 빌드하여 격리된 개발 환경에 배포를 참조하십시오.
참고
팀 환경에서는 변경 내용을 프로덕션 서버에 배포하기 전에 응용 프로그램 및 데이터베이스 단위 테스트를 실행해야 합니다. 자세한 내용은 팀 데이터베이스 개발 시작을 참조하십시오.
이름을 바꾸기 전에 고려할 사항
다음 중 하나라도 해당되는 경우 데이터베이스 개체에 대한 참조 이름을 바꾸기 전에 추가로 고려할 사항을 이해하고 있어야 합니다.
뷰의 열 이름을 바꾸려는 경우
하나 이상의 오류가 포함되어 올바르게 빌드할 수 없는 데이터베이스 프로젝트에서 개체 이름을 바꾸려는 경우
저장하지 않은 데이터 생성 계획이 열려 있는 경우
프로젝트에 데이터 바인딩된 생성기를 사용하는 데이터 생성 계획이 있는 경우
정규화된 이름을 사용하지 않는 데이터베이스 단위 테스트가 있고 이 테스트에서 다른 스키마 또는 데이터베이스의 개체를 참조하는 경우
프로젝트에 정규화된 이름을 사용하지 않는 데이터베이스 스크립트가 있고 이 스크립트에서 다른 스키마 또는 데이터베이스의 개체를 참조하는 경우
이러한 경우 특별히 고려해야 할 사항에 대한 자세한 내용은 데이터베이스 개체의 이름을 바꾸기 전 고려 사항을 참조하십시오.
일반 작업
다음 표에서는 이 시나리오를 지원하는 일반적인 작업에 대한 설명과 해당 작업을 성공적으로 완료하는 방법에 대한 자세한 내용을 볼 수 있는 링크를 보여 줍니다.
Task |
지원 항목 |
|---|---|
실습: 연습 과정을 따라 다른 형식의 리팩터링 외에도 데이터베이스 개체를 다른 스키마로 이동하는 방법을 익힐 수 있습니다. 기초 연습을 완료하여 데이터베이스 개발 주기의 일부로 리팩터링을 사용하는 방법도 알아볼 수 있습니다. |
|
데이터베이스 개체 이름 바꾸기: 리팩터링을 사용하여 데이터베이스 프로젝트의 데이터베이스 개체에 대한 모든 참조를 변경할 수 있습니다. 리팩터링 작업의 일부로 변경 내용을 적용하기 전에 미리 볼 수 있습니다. |
|
리팩터링 작업 실행 취소: 리팩터링 작업을 되돌려야 하는 경우 Visual Studio의 현재 세션에서 해당 리팩터링 작업의 실행을 취소할 수 있습니다. |
|
데이터베이스 리팩터링 변경 내용 배포: 데이터베이스 프로젝트를 리팩터링한 후에는 해당 변경 내용을 대상 데이터베이스에 배포해야 합니다. 일반적으로 변경 내용을 버전 제어에 체크 인하기 전에 격리된 개발 환경에 배포하여 테스트합니다. |
|
문제 해결: 데이터베이스 리팩터링과 관련된 일반적인 문제를 해결하는 방법에 대해 알아보십시오. |