효과적인 버전 저장 절차는 어떻게됩니까?

Question

나는 큰 eshop을 위해 wotking하는 데이터베이스 개발 팀의 일원이다. 우리는 MS SQL 2016과 ASP.NET을 사용하고 있습니다. SQL Server는 프로덕션 환경에서 연결 풀링 (aprox 7-10k 배치/초)을 사용하는 10 개 이상의 IIS 서버의 클라이언트가 사용하며 18 개의 DEV/TESTING IIS 서버 (멀티 TB 크기이기 때문에 하나의 DEV 데이터베이스 만 사용)를 사용합니다. 우리는 기존 저장 프로 시저를 자주 변경해야하는 새로운 기능을 개발합니다.

프로덕션 환경에 변경 사항을 배포하는 경우 응용 프로그램 수정을 IIS로 변경하고 데이터베이스 절차를 변경하는 작업의 일부입니다. 배포하는 경우 항상 IIS 서버 5 개로 변경된 다음 IIS 서버 5 개로 변경됩니다. 그 전까지는 IIS 서버에 이전 버전과 새 버전이 모두 존재합니다. 이러한 버전은 데이터베이스의 프로 시저를 동시에 사용하는 동안 잠시 동안 공존해야합니다. 데이터베이스 레벨에서 우리는 프로 시저에 대해 여러 버전을 사용하여이 상황을 해결합니다. 오래된 앱 버전은 EXEC dbo.GetProduct를 호출하고 새로운 앱 버전은 dbo.GetProduct_v2를 사용합니다. 모든 IIS에 응용 프로그램의 새 버전을 배포하면 모두가 dbo.GetProduct_v2를 사용하고 있습니다. 다음 배포에서는 상황이 바뀌고 dbo.GetProduct에 새 버전이 포함됩니다. 비슷한 상황이 개발 및 테스트 환경에 있습니다.

나는이 솔루션이 이상적이지 않고 영감을 받고 싶다는 것을 충분히 알고 있습니다.

데이터 부분과 논리 부분을 분리하는 것을 고려합니다. 하나의 데이터베이스에는 데이터 테이블이 있고, 다른 데이터베이스에는 프로 시저 및 기타 프로그램 개체 만 포함됩니다. 새 버전을 배포 할 때 논리를 포함하는 전체 데이터베이스의 새 버전을 배포하기 만하고 절차 버전을 만들 필요가 없습니다. 논리 데이터베이스의 프로시 저는 데이터로 데이터베이스를 조회합니다. 그러나이 솔루션의 단점은 다른 데이터베이스에서의 쿼리를 지원하지 않기 때문에 내년에 사용할 기본 컴파일 된 프로 시저를 사용할 수 없다는 것입니다. 또 다른 옵션은 하나의 데이터베이스와 다른 스키마에서 별도의 절차 버전을 사용하고

... 당신은 어떤 아이디어, 프로/단점이 있거나 우리를 도와하고 관리 할 수있는 도구를 알고 있다면

이/배포/여러 PROC 버전을 사용 , 의견을 말하십시오. 우리는 TFS와 힘내를 사용하고 있지만, 이것은 SQL 데이터베이스에 절차의 버전을 해결하지 않습니다

는

편집 정말 고마워요. 내 주요 질문은 데이터베이스의 여러 버전의 절차를 사용하여 여러 버전의 IIS 응용 프로그램을 관리해야하는 필요성을 처리하는 방법입니다.

Answer 1

SSDT 또는 SQL Compare와 소스 제어로 버전 관리가 쉽습니다. 배포도 마찬가지입니다.

문제는 버전을 지정하지 않습니다.

이름이 같지만 매개 변수는 같지만 코드가 다르며 결과가 다른 두 개의 다른 저장 프로 시저가 필요합니다. 과부하를 사용할 수 있기 때문에 .net 코드에서 더 달성 할 수 있습니다. 귀하의 문제가 입니다

다른 코드를 사용하여 배포를 단계적으로 동일해야 시저의
두 가지 버전을 공존.

귀하의 경우, 동의어를 사용하여 실제 저장 프로 시저 이름을 마스크하는 것이 좋습니다.

이렇게 저장 프로 시저가 있습니다.

• dbo.GetProduct_v20170926 (마지막 릴리스)
• dbo.GetProduct_v20171012 (이 자료)
• dbo.GetProduct_v20171025 (다음 버전)
• dbo.GetProduct_v20171113 (하나씩)

다음 너는

CREATE SYNONYMN dbo.GetProductBlue FOR dbo.GetProduct_v20171012; 
CREATE SYNONYMN dbo.GetProductGreen FOR dbo.GetProduct_v20170926; 

너 r은 동일한 결과를 다른 스키마입니다 사용

DROP SYNONYMN dbo.GetProductBlue; 
CREATE SYNONYMN dbo.GetProductBlue FOR dbo.GetProduct_v20171025; 

다음

DROP SYNONYMN dbo.GetProductGreen; 
CREATE SYNONYMN dbo.GetProductGreen FOR dbo.GetProduct_v20171113; 

... IIS 배포가 SYNONYMNs

다음 릴리스 중 하나를 참조 단계적하지만 당신은

로 끝날 것

또는 릴리스 날짜를 스키마 이름으로 코딩하십시오.

- Codev20171025.GetProduct 
- Codev20171113.GetProduct 

는 당신은 당신이 IIS 서버의 또 다른 세트를 가지고 같은 문제가 및 서버의 각 세트에 하나 개의 코드베이스를 유지하는 것 :

는 blue/green deployment model

Answer 2

몇 가정을 기준으로합니다.

• 당신은 어딘가에 IIS 코드의 버전 번호가 - 아마의 App.config Web.config 또는 파일 및 해당 버전 번호가 .NET 코드에서 참조 할 수 있습니다
• 당신의 목표는 당신의 IIS를 변경하지 않습니다 모든 릴리스에 .NET의 SP 이름 그러나 그것이 SP의
• 모든 버전은 SP의
• 다른 버전은 다른 결과

을 반환 할 수 있습니다 같은 매개 변수를 DB에 SP의 올바른 버전을 호출이 울 적시에 DB에 저장 프로 시저의 여러 버전을 갖는 방법이 없습니다. 아이디어는 가능한 한 많이 IIS에서 제거하는 것입니다 (나는 추측하고 있습니다).

위의 내용을 토대로 IIS에 Web.config에서 얻을 수있는 버전 번호를 허용하는 다른 매개 변수를 SP에 추가 할 수 있다고 생각합니다.

저장된 프로 시저 dbo.GetProduct은 "컨트롤러"또는 "라우팅"저장 프로 시저가됩니다.이 프로 시저의 유일한 목적은 버전 번호를 가져 와서 나머지 매개 변수를 적절한 기본 SP에 전달하는 것입니다.

버전 당 SP가 1 개 (원하는 이름 지정 규칙을 사용하십시오). 그리고 dbo.GetProduct은 전달 된 버전 번호를 기반으로 적절한 번호를 호출합니다. 아래 예가 있습니다.

create proc dbo.GetProduct_v1 @Param1 int, @Param2 int 
as 
begin 
    --do whatever is needed for v1 
    select 1 
end 

go 

create proc dbo.GetProduct_v2 @Param1 int, @Param2 int 
as 
begin 
    --do whatever is needed for v2 
    select 2 
end 

go 

create proc dbo.GetProduct @VersionNumber int, @Param1 int, @Param2 int 
as 
begin 
    if @VersionNumber = 1 
    begin 
     exec dbo.GetProduct_v1 @Param1, @Param2 
    end 

    if @VersionNumber = 2 
    begin 
     exec dbo.GetProduct_v2 @Param1, @Param2 
    end 
end 

또 다른 생각은 동적으로 대신 하드은 SP 이름을 코딩의 (의 Web.config의 버전 번호 기준) IIS에서 SP 이름을 구축하는 것입니다.