私が取り組んでいるシステムには、SQLServerのストアドプロシージャにほとんどすべてのロジックが含まれています。開発慣行を改善する一環として、機能フラグ(別名トグル)を使用して継続的デリバリーモデルに移行し、本番環境で機能を有効にします。
ストアドプロシージャを記述して、フラグを効率的にチェックし、プロシージャが呼び出されるたびに構成テーブルをハンマーで処理してデータベースに負荷をかけないようにするにはどうすればよいですか?
私が取り組んでいるシステムには、SQLServerのストアドプロシージャにほとんどすべてのロジックが含まれています。開発慣行を改善する一環として、機能フラグ(別名トグル)を使用して継続的デリバリーモデルに移行し、本番環境で機能を有効にします。
ストアドプロシージャを記述して、フラグを効率的にチェックし、プロシージャが呼び出されるたびに構成テーブルをハンマーで処理してデータベースに負荷をかけないようにするにはどうすればよいですか?
存在するかどうかわからないパフォーマンスの問題を時期尚早に最適化する必要があるとは思いません。テーブルに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行のテーブルでは、パフォーマンスが低下すると思われるほどパフォーマンスが低下することはありません...
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.
醜い部分は、ビットの意味を管理することです。