나는에 관한 정보를 찾고 있어요 다음모범 사례는
DB 스키마 변경을 DB 내 생산에 내 dev에 DB의 스키마를 업데이트하거나 더 간결하게 만들기위한 가장 좋은 방법은 무엇입니까 일반적으로
프로덕션 데이터베이스는 두 개의 다른 ASP.NET 웹 사이트의 백 엔드입니다.
우리의 스키마 변경 프로세스는 실제로 "마이그레이션"이 실제로 스키마 변경 내용을 포함하는 .cs 파일이되어 매우 견고합니다. 그런 다음 ADO.NET을 사용하여 db에 대해 스키마 변경 사항을 적용합니다.
제 질문은 데이터베이스 연결에 대한 것입니다.
db에 액세스하는 두 개의 웹 사이트를 중지해야합니까? 나는해야한다고 생각합니다. DB를 단일 사용자 모드로 설정해야합니까? 내가해야 할 것처럼 보이지만 나는 그것에 대해 전적으로 자신감이 없습니다.
무엇이 누락 될 수 있습니까? 전에 DB 스키마 변경에 대해 당신을 물 렸던 것들은 무엇입니까?
업데이트로 인해 열 이름, 저장된 proc 매개 변수 등이 변경되면 스키마 업데이트를 수행하기 전에 항상 앱을 오프라인으로 설정하십시오.
업데이트가 정상적인 데이터 처리에 영향을 미치지 않는 경우에만 일 수 있습니다. "핫"할 수 있습니다. 이 카테고리는 인덱스, 테이블 등을 추가 할 때입니다.
스키마 업데이트가 처리되는 동안 다른 사람이 앱을 사용하는 경우 데이터 일관성이 손상되는 상황에 처할 수도 있습니다.
이 업데이트를 사용하려면 웹 응용 프로그램 파일에 대한 해당 업데이트가 필요한 경우 업데이트를 수행하기 전에 사이트를 오프라인으로 설정하십시오. 페이지를보고있는 사람이 누구인지 알 수 없으며 오류 만 표시하려면 제출을 클릭하십시오 ...
일반적으로 이러한 종류의 유지 관리는 사용량이 가장 적은 시간에 수행됩니다. 사이트가 다운되는 시간과 기간에 관해 미리 사용자에게 알리고 싶을 것입니다.
또한 Redgate의 SQL Compare와 같은 도구를 사용하여 db 업데이트를 스크립팅합니다. 이 작업은 실제 밀어 넣기 전에 프로덕션 데이터에서 새로 고쳐진 준비 서버에서 실행되어 놀라움이 없도록하고 매우 빠르게 수행 할 수 있습니다.
단일 사용자 모드와 관련하여 일반적으로이 기능을 사용하여 단일 관리 스튜디오 인스턴스에 대한 데이터베이스 액세스를 제한합니다. 우리가 배포 할 때 일반적으로하는 일이 아닙니다.
이상적인 상황이지만 항상 달성 가능한 것은 아닙니다. V < 이전 버전의 > 웹 사이트 버전과 호환되는 스키마를 변경합니다. 그런 다음 웹 서버에 V < 새 >을 릴리스합니다. 모든 웹 서버가 V 까지 완료되면 정리 (누락 된 값 등 채우기)를 수행 한 다음 적절한 null 가능성 변경을 수행 할 수 있습니다.
.cs/ado.net 경로가 스키마 변경을 고려하지 않았습니다. 우리가하는 일은 델타 (delta)를 만드는 것입니다 .SQL 파일 - SQL을 변경합니다. 이러한 변경 사항은 알려진 버전의 스키마에 따라 변경되어 변경되고 .SQL은 배포 과정의 일부입니다.
우리가 할 수있는 한 최선을 다해 열, 색인 등의 존재와 같은 특정 항목에 대한 스키마를 확인하여 여러 번 실행하도록 시도합니다. 그런 식으로 실수로 여러 번 실행될 수 있습니다.
배포 할 때 우리는 하루 중 특정 시간대, 사용자/고객 경고, 웹 사이트 종료 등을 경고합니다. 개발 및 준비 서버에서 거의 매일 진행되는 '연습'배포로 출시 전 마지막 날 최종 배포 신뢰도가 높습니다.
스키마 변경 사항을 SQL에 보관하면 변경되는 '마스터'스키마 SQL처럼 보이게되므로 더 쉽게 추적 할 수 있습니다. 디버그도 적습니다!
이들은 나머지 코드와 함께 TFS에서도 관리됩니다.
여러 번 실행하면 접선이 안전합니다.이 속성은 멱 (idempotence)이라고합니다. .SQL 파일은 멱등 원입니다. –