2017-10-12 48 views
2

我是數據庫開發團隊爲大eshop服務的一部分。我們正在使用MS SQL 2016和ASP.NET。在生產環境中,10臺使用連接池的IIS服務器的客戶端使用SQL Server(我們有7-10k批/秒),我們使用18臺DEV/TESTING IIS服務器(但由於多TB大小,只有一個DEV數據庫)。 我們開發了一個新功能,迫使我們經常更改現有的存儲過程。如何有效的版本存儲程序?

如果我們正在部署對生產環境的更改,它將更改應用程序對IIS的修改以及數據庫過程中的更改。部署時,它們總是更改爲5個IIS服務器,然後更改爲5個。同時,IIS服務器上都存在舊版本和新版本。這些版本必須同時共存一段時間,同時使用數據庫中的過程。在數據庫級別,我們通過使用多個版本來解決這種情況。舊的應用程序版本調用EXEC dbo.GetProduct,新的應用程序版本使用dbo.GetProduct_v2。將新版本的應用程序部署到所有IIS後,每個人都使用dbo.GetProduct_v2。在下一次部署期間,情況會逆轉,並且dbo.GetProduct將包含新版本。類似的情況在於開發和測試環境。

我完全意識到這個解決方案並不理想,我想受到啓發。

我們考慮分離數據部分和邏輯部分。在一個數據庫中會有數據表,其他數據庫將只包含程序和其他程序對象。部署新版本時,我們只需部署包含邏輯的整個數據庫的新版本,而不需要創建過程的版本。來自邏輯數據庫的程序將用數據查詢數據庫。 但是,這種解決方案的缺點是不可能使用我們計劃明年使用的本機編譯過程,因爲它們不支持在其他數據庫中查詢。

另一種選擇是使用一個數據庫,並在不同的模式不同的程序版本...

如果您有任何意見,優點/缺點,或者你知道什麼樣的工具可以幫助我們和管理/部署/使用多個版本PROC請發表評論。

謝謝你這麼多

編輯:我們正在使用TFS和Git,但是這並沒有解決在SQL數據庫的程序版本。我的主要問題是如何處理使用數據庫中多個版本的過程來管理多個IIS應用程序版本的需求。

+0

你看過像GIT這樣的源代碼庫嗎?還有很多其他的選擇,但那真的是你想要投資的東西。https://git-scm.com/ –

+0

當有人問一個問題時,它招待我,但他們的帖子完全由陳述關於該問題的不正確信息組成。如果您使用正確的項目和工具,TFS/Git肯定可以解決版本控制的問題。看看Schema Compare。 –

+0

你的最終目標是什麼?不必在您的IIS代碼中更改SP引用?然後才能夠在DB中管理SP版本? – thomas

回答

2

通過SSDT或SQL比較和源代碼控制,版本控制非常簡單。部署也是如此。

您的問題不是版本控制。

您需要兩個具有相同名稱的不同存儲過程,可能參數相同,但代碼不同,結果可能不同。例如,.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分階段部署IIS指的是SYNONYMNs

下釋放一個...

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

然後

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

使用不同的模式是一樣的結果,但你最終與

- Blue.GetProduct 
- Green.GetProduct 

或者將您的發佈日期編碼到架構名稱中。

- Codev20171025.GetProduct 
- Codev20171113.GetProduct 

你最好有同樣的問題,即使你有另一套IIS服務器,並保持一個代碼基礎上的每一組服務器:基於blue/green deployment model

+0

這些感覺就像OP已經在做的一樣,只有一層抽象層(SYNONYMN)。我可能會錯過這個區別。 – thomas

+0

@ thomas:true,它只是穩定了客戶端代碼的API,使得它更加明顯,哪個版本正在使用 – gbn

1

一對夫婦的假設

  • 您的IIS代碼版本號的地方 - 也許一個app.config或Web.config文件和版本號可以在你的.NET代碼中引用
  • 你的目標是不是要改變你的IIS每個版本的.NET SP的名稱,但它調用SP的正確版本DB
  • SP的所有版本採用相同的參數
  • 不同版本的SP可以返回不同的結果

UL在數據庫中存在多個版本的存儲過程是毫無意義的。這個想法是儘可能地從IIS中抽象出來(我假設)。

基於上述,我認爲你可以添加另一個參數到你的SP接受版本號(你可能會從IIS中的Web.config獲得)。

然後,您的存儲過程dbo.GetProduct成爲一個「控制器」或「路由」存儲過程,其唯一目的是獲取版本號並將其餘參數傳遞給適當的底層SP。

因此,每個版本都會有1個SP(使用您希望的任何命名約定)。並且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 

另一個想法是動態建立在IIS中的SP名稱(根據Web.config中的版本號),而不是硬編碼的SP名稱。

相關問題