一意のインデックスの最大16列を回避する方法

CREATE INDEXドキュメントによると：

最大16列を単一の複合インデックスキーに組み合わせることができます。

一意の組み合わせを形成する必要がある〜18列のテーブルがあります。このテーブルはパフォーマンスの影響を受けません -値を更新したりレコードを挿入したりすることはほとんどありません。レコードが重複しないようにする必要があるだけです。単純な一意性の制約を課すことができると考えました。

何か案は？より良い方法がある場合は、一意のインデックス/制約を完全に回避することにオープンです。

18個のキーを組み合わせた永続的な計算列を追加してから、計算列に一意のインデックスを作成します。

alter table t add all_keys as c1+c2+c3+...+c18 persisted;
create unique index i18 on t (all_keys);

計算列でのインデックスの作成を参照してください。

もう1つの方法は、インデックス付きビューを作成することです。

create view v 
with schemabinding
as select c1+c2+c3+...+c18 as all_keys
from dbo.t;

create unique clustered index c18 on v(all_keys);

インデックス付きビューの作成を参照してください。

どちらのアプローチでも部分的なキー集計が可能です。c1+ c2 + c3をk1、c4 + c5 + c6をk2として集計し、（k1、k2、...）でインデックス付きビューをインデックス付け/作成します。チアは、範囲スキャンに役立つ可能性があります（インデックスはc1 + c2 + c3の検索に使用できます。

もちろん、+私の例のすべての操作は文字列集計です。実際に使用する演算子は、それらのすべての列のタイプによって異なります（つまり、明示的なキャストを使用する必要がある場合があります）。

PS。一意の制約は一意のインデックスによって適用されるため、一意のインデックスに対する制限は一意の制約にも適用されます。

create table t (
    c1 char(3), c2 char(3), c3 char(3), c4 char(3),
    c5 char(3), c6 char(3), c7 char(3), c8 char(3),
    c9 char(3), c10 char(3), c11 char(3), c12 char(3),
    c13 char(3), c14 char(3), c15 char(3), c16 char(3),
    c17 char(3), c18 char(3), c19 char(3), c20 char(3),
    constraint unq unique
      (c1,c2,c3,c4,c5,c6,c7,c8,c9,c10,c11,c12,c13,c14,c15,c16,c17,c18));
go  


Msg 1904, Level 16, State 1, Line 3
The index '' on table 't' has 18 column names in index key list. 
The maximum limit for index or statistics key column list is 16.
Msg 1750, Level 16, State 0, Line 3
Could not create constraint. See previous errors.

ただし、永続的な計算列に制約を作成すると機能します。

create table t (
    c1 char(3), c2 char(3), c3 char(3), c4 char(3),
    c5 char(3), c6 char(3), c7 char(3), c8 char(3),
    c9 char(3), c10 char(3), c11 char(3), c12 char(3),
    c13 char(3), c14 char(3), c15 char(3), c16 char(3),
    c17 char(3), c18 char(3), c19 char(3), c20 char(3),
    all_c as 
        c1+c2+c3+c4+c5+c6+c7+c8+c9+c10+c11+
        c12+c13+c14+c15+c16+c17+c18 
        persisted
        constraint unq unique (all_c));
go  

明らかに、永続化された列はディスク上のスペースを消費するため、非常に大きなテーブルではアプローチが不適切になる場合があります。インデックス付きビューのアプローチにはこの問題はありません。計算された列とインデックスのスペースではなく、インデックスのスペースを消費するだけです。

HASHBYTES('MD5', ...)18個の列の組み合わせを使用して生成された計算列に一意のインデックスチェックを配置する方がはるかに良いと思います。

私はこの問題に遭遇し、私の上級DBAは一意性チェック機能の使用を提案しました。私の挿入は比較的小さく、頻度が低く（約1000行、毎月の初めに挿入）、唯一の懸念は一意性の強制です。

CREATE FUNCTION dbo.fn_UQ_table1 ()  
RETURNS BIT

AS
BEGIN
      DECLARE @ResultBit BIT = 1

      IF EXISTS(
      SELECT COUNT(*)
      FROM [table1]
      GROUP BY [c1],[c2],[c3],[c4],[c5],[c6],
            [c7],[c8],[c9],[c10],[c11],[c12],
            [c13],[c14],[c15],[c16]
      HAVING COUNT(*) > 1)
      SELECT @ResultBit = 0

      RETURN      @ResultBit

END

SELECT dbo.fn_UQ_table1()

ALTER TABLE [table1]  
WITH NOCHECK ADD  
CONSTRAINT [CK_UQ] CHECK  (([dbo].[fn_UQ_table1]()=1))

@RBarryYoung、まだコメントする担当者がいませんが、データ型の1つが日時だったためHASHBYTESソリューションに問題があり、オプションのスタイル引数を提供していないという初心者（？）の間違いを犯しましたvarcharに変換するときのCONVERT関数。スタイルがないと、PERSISTED UNIQUE NONCLUSTERED制約を追加しようとすると次のエラーが発生します。

"column 'key_hash' in table 'table1' cannot be persisted because 
the column is non-deterministic."

いくつかの値を組み合わせて、新しい一意の値を作成し、現在のデータに加えてそれを保存することができます。

新しい値を作成するユーザー定義関数を作成し、データが追加されたときにフィールドにデータを入力するトリガーを作成すると、フィールドのメンテナンスにかかるオーバーヘッドが大幅に減ります。

2つまたは3つのフィールドを組み合わせると、16の制限を下回ります。

insert/のトリガーで行くことができupdateます。の句を使用して、列ごとにグループ化を選択しますhaving count(*) > 1。それが空ではない場合は、ロールバックします。

これが私がすることです。INSERT、UPDATEのROW_NUMBER ()機能を実行するAFTERトリガーを作成し、一意の18列すべてでパーティション化します。最大行数が1より大きい場合は、を実行しROLLBACKます。