我有一个我正在处理的系统,它几乎具有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 行的表格不会像你想象的那样拖累你的表现......
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.
丑陋的部分是管理位的含义。