SQL AzureフェデレーションがIDENTITYプロパティまたはSEQUENCEをサポートしていないことを考慮すると、レコードを挿入するときに連続番号を生成する効率的な方法はありますか?例えばSQL Azureフェデレーションでシーケンシャル番号を効率的に生成する
、これらのカラムを持つテーブルを与え:
CREATE TABLE [dbo].[Orders] (
[TenantId] [uniqueidentifier] NOT NULL,
[OrderId] [uniqueidentifier] NOT NULL,
[OrderNumber] [int] NOT NULL
CONSTRAINT [PK_Orders] PRIMARY KEY CLUSTERED (
[TenantId] ASC,
[OrderId] ASC
)
) FEDERATED ON ([FederationKey] = [TenantId])
所与のテナントのために挿入された各注文のため、OrderIdでインクリメントされるべきです。たとえば、テントAの場合、OrderIdは1,2,3 ...であり、テナントBのOrderIdも1,2,3 ...となります。理想的には、ギャップがないはずです。
TenantIdとOrderIdは主キーのコンポーネントです。それらの値はアプリケーションによって設定され、シーケンス生成の問題には関係しません。 OrderIdだけがビジネス上の意味を持つ連続番号を持っています。また、TenantIdは、連合の配布鍵です。
This MSDN Blog articleは、シーケンスを保持するテーブルを有し、分離されたトランザクション内のストアドプロシージャを使用してシーケンスをインクリメントするアプローチを説明する。各テナントは、シーケンスの最後に使用された値を保持するこのテーブルのレコードを保持します。
これは、スケーラビリティ、競合、リソースロックを考慮した最適なアプローチですか? SQL Azureフェデレーションの制限を考慮して、他の便利なトリックですか?
グレート答え、私は私の質問に引用されたオプションに加えて、 (ストアド・プロシージャを使用して別の接続を使用してレコードを更新する)場合、最初の選択肢は、スケーラビリティとスループットを大幅に向上させますが、第2の選択肢は非常に単純であり、プロセスが合理化されている(例えば、メッセージキューを使用している)場合、または各テナントごとの新規注文作成の割合が高すぎない場合には十分である。 –