2012-08-07 27 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. 

丑陋的部分是管理的含义为位。