我有一个系统,我正在努力,几乎所有的SQL Server存储过程的逻辑。作为改进开发实践的一部分,我们希望通过使用功能标志(也称为切换)来实现持续交付模式,以实现生产中的功能。你如何做存储过程功能标志
我该如何编写存储过程,以便他们有效地检查标志,并且不会在每次调用过程时通过敲击配置表来加载数据库?
我有一个系统,我正在努力,几乎所有的SQL Server存储过程的逻辑。作为改进开发实践的一部分,我们希望通过使用功能标志(也称为切换)来实现持续交付模式,以实现生产中的功能。你如何做存储过程功能标志
我该如何编写存储过程,以便他们有效地检查标志,并且不会在每次调用过程时通过敲击配置表来加载数据库?
我不相信你需要过早地优化一个你不知道会出现的性能问题。如果你的表有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排桌子不会像你想象的那样拖累你的表演...
我喜欢这种方法,虽然它是一个标志检查而不是版本检查。这让我意识到来自应用程序而不是数据库的标志可能会更好 - 这是我想到的方法,因为我们习惯于在proc中做所有事情。如果它来自应用程序,我可以将值存储在配置文件中,以便在应用程序和数据库中使用。 – 2012-08-07 03:38:19
您可以使用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.
丑陋的部分是管理的含义为位。
我们在谈论多少旗帜/功能?平均存储过程多久调用一次?新特性所要求的典型变化的性质是什么?在我以前的工作中,我们几乎可以将所有功能增强功能完全向后兼容 - 应用程序在我们需要它们之前不知道它们。 – 2012-08-07 01:29:55
长时间调用Procs - 这是一个非常大而且繁忙的应用程序。作为正常发展的一部分,随着时间的推移,旗帜的数量将会增加。他们会定期被淘汰,但我不确定什么是高水位标记 - 我估计超过100个。 – 2012-08-07 01:32:33
你能举出一个取决于国旗的程序行为变化的例子吗? – 2012-08-07 01:33:13