3

私が取り組んでいるシステムには、SQLServerのストアドプロシージャにほとんどすべてのロジックが含まれています。開発慣行を改善する一環として、機能フラグ（別名トグル）を使用して継続的デリバリーモデルに移行し、本番環境で機能を有効にします。

ストアドプロシージャを記述して、フラグを効率的にチェックし、プロシージャが呼び出されるたびに構成テーブルをハンマーで処理してデータベースに負荷をかけないようにするにはどうすればよいですか？

4

2 に答える 2

2

存在するかどうかわからないパフォーマンスの問題を時期尚早に最適化する必要があるとは思いません。テーブルに100行があり、頻繁に参照される場合、ほぼ確実に100％の時間メモリ内にあり、アクセスは問題になりません。

コードを上位互換にする1つの方法は、デフォルト値を使用してパラメーターをプロシージャに追加することです。アプリは、アップグレードの準備ができたときに「アップグレード」できます。これは構成ファイルパラメーターを介して実行できますが、とにかく新しい機能を利用するには、おそらくアプリを再コンパイルする必要があります。

簡単な例として：

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行のテーブルでは、パフォーマンスが低下すると思われるほどパフォーマンスが低下することはありません...

于 2012-08-07T02:40:06.380 に答える
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.

醜い部分は、ビットの意味を管理することです。

于 2012-08-07T02:36:13.047 に答える