Question

我有一个我正在研究的系统，它在SQL Server存储过程中几乎具有所有逻辑。作为改进开发实践的一部分，我们希望使用功能标记（也称为切换）转移到持续交付模型，以便在生产中启用功能。

如何编写存储过程以便它们有效地检查标志，并且不会在每次调用过程时通过敲击配置表来为数据库添加负载？

Answer 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.

丑陋的部分是管理比特的含义。

Answer 2

我不相信你需要过早地针对你不知道会存在的性能问题进行优化。如果你的表有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排表不会像你认为的那样拖累你的表现......

如何使用存储过程执行功能标记

2 个答案: