2012-08-07 59 views
1

我有一個系統,我正在努力,幾乎所有的SQL Server存儲過程的邏輯。作爲改進開發實踐的一部分,我們希望通過使用功能標誌(也稱爲切換)來實現持續交付模式,以實現生產中的功能。你如何做存儲過程功能標誌

我該如何編寫存儲過程,以便他們有效地檢查標誌,並且不會在每次調用過程時通過敲擊配置表來加載數據庫?

+0

我們在談論多少旗幟/功能?平均存儲過程多久調用一次?新特性所要求的典型變化的性質是什麼?在我以前的工作中,我們幾乎可以將所有功能增強功能完全向後兼容 - 應用程序在我們需要它們之前不知道它們。 – 2012-08-07 01:29:55

+0

長時間調用Procs - 這是一個非常大而且繁忙的應用程序。作爲正常發展的一部分,隨着時間的推移,旗幟的數量將會增加。他們會定期被淘汰,但我不確定什麼是高水位標記 - 我估計超過100個。 – 2012-08-07 01:32:33

+0

你能舉出一個取決於國旗的程序行爲變化的例子嗎? – 2012-08-07 01:33:13

回答

1

我不相信你需要過早地優化一個你不知道會出現的性能問題。如果你的表有100行並且經常被引用,它幾乎肯定會在100%的時間內訪問內存,並且訪問不會成爲問題。

我們使代碼向前兼容的一種方式是使用默認值向過程添加參數,並在應用程序準備好時可以「升級」應用程序。這可以通過一個配置文件參數來完成,但大概應用程序將不得不重新編譯以利用新功能。

作爲一個簡單的例子:

CREATE PROCEDURE dbo.doStuff 
    @version DECIMAL(10,2) = 1.0 
AS 
BEGIN 
    SET NOCOUNT ON; 

    IF @version >= 1.1 
    BEGIN 
    PRINT 'This only executes if the app tells us it is 1.1 or newer.'; 
    END 

    IF @version >= 2.5 
    BEGIN 
    PRINT 'This only executes if the app tells us it is 2.5 or newer.'; 
    END 
END 
GO 

當所有的應用程序都是最新的,可以增加對參數的基礎版本。否則,它們都可以按照它們自己的費率進行更新,並且模式可以以不同的速率進行。如果您可以將每個功能與順序點發布相關聯,則這不應該太難管理。但是,我會再次堅持認爲,100排桌子不會像你想象的那樣拖累你的表演...

+0

我喜歡這種方法,雖然它是一個標誌檢查而不是版本檢查。這讓我意識到來自應用程序而不是數據庫的標誌可能會更好 - 這是我想到的方法,因爲我們習慣於在proc中做所有事情。如果它來自應用程序,我可以將值存儲在配置文件中,以便在應用程序和數據庫中使用。 – 2012-08-07 03:38:19

1

您可以使用CONTEXT_INFO在會話或連接的整個生命週期中存儲128個字節的標誌。

創建一個函數來檢索標誌值:

create function dbo.GetConfigFlags() returns VarBinary(128) 
    begin 
    -- Retrieve the configuration flag values. 
    -- This can be context sensitive, e.g. return different values based on user, server, ... . 
    declare @Result as VarBinary(128) 
    if Context_Info() is NULL 
    set @Result = 12345 -- Get value from table or hard code here. 
    else 
    set @Result = Context_info() 
    return @Result 
    end 

開始與代碼中的每個存儲過程,得到標誌,如果它們還沒有裝載:

if Context_Info() is NULL 
    begin 
    declare @ConfigFlags as VarBinary(128) = dbo.GetConfigFlags() 
    set Context_Info @ConfigFlags -- This is not allowed within a function. 
    end 
select Context_Info() -- Demo. 

醜陋的部分是管理的含義爲位。