web-dev-qa-db-ja.com

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

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

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

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

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

sql-serversql-server-2008database-designconstraint
8
Nick B

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、...）でインデックス付きビューをインデックス付け/作成します。 Thiaは範囲スキャンに役立つ可能性があります（インデックスは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

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

14
Remus Rusanu

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

13
RBarryYoung

私はこの問題に遭遇し、私の上級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
Apoxy

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

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

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

0
Tony

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

0
Ben Thul

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

0
Thomas Stringer