Qualquer maneira de contornar o índice único 16 no máximo

De acordo com a CREATE INDEXdocumentação:

Até 16 colunas podem ser combinadas em uma única chave de índice composta.

Temos uma tabela com ~ 18 colunas que precisam formar uma combinação única. Esta tabela não é sensível ao desempenho - raramente atualizamos valores / inserimos registros. Só precisamos garantir que evitamos duplicar nossos registros ... e pensamos que poderíamos impor uma restrição de exclusividade simples.

Alguma ideia? Estou aberto a evitar inteiramente o índice / restrição exclusivo, se houver uma maneira melhor.

Adicione uma coluna computada persistente que combine as 18 teclas e crie um índice exclusivo na coluna computada:

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

Consulte Criando índices em colunas computadas .

Outra abordagem é criar uma exibição indexada:

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);

Consulte Criando vistas indexadas .

Ambas as abordagens permitem um agregado de chave parcial: agregado c1 + c2 + c3 como k1, c4 + c5 + c6 como k2 etc., em seguida, indexa / cria uma exibição indexada em (k1, k2, ...). Tia pode ser benéfico para varreduras de intervalo (o índice pode ser usado para pesquisa em c1 + c2 + c3.

Obviamente, todas as +operações no meu exemplo são agregação de cadeias, o operador real a ser usado depende dos tipos de todas essas colunas (por exemplo, você pode precisar usar projeções explícitas).

PS. Como restrições exclusivas são impostas por um índice exclusivo, qualquer restrição em índices exclusivos também se aplica a restrições exclusivas:

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.

No entanto, a criação da restrição em uma coluna computada persistente funciona:

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  

Obviamente, a coluna persistente consome o espaço no disco, portanto a abordagem pode ser ruim para uma tabela muito grande. A abordagem de exibição indexada não apresenta esse problema, apenas consome o espaço para o índice , não o espaço para a coluna e o índice calculados .

Eu acho que você faria muito melhor colocar sua verificação de índice exclusiva em uma coluna computada que é gerada usando HASHBYTES('MD5', ...)a combinação de suas 18 colunas.

Encontrei esse problema e meu DBA sênior sugeriu o uso de uma função de verificação de exclusividade. Minhas inserções são relativamente pequenas e pouco frequentes (~ 1.000 linhas, inseridas no início de cada mês) e minha única preocupação é reforçar a exclusividade.

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, ainda não tenho o representante para comentar, mas tive problemas com a solução HASHBYTES porque um dos meus tipos de dados era uma data e hora e cometi o erro de novato (?) De não fornecer o argumento de estilo opcional ao meu Função CONVERT ao converter para varchar. Sem o estilo, você obtém o seguinte erro ao tentar adicionar as PERSISTED UNIQUE NONCLUSTEREDrestrições:

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

Você pode combinar alguns dos valores para criar um novo valor exclusivo e armazená-lo, além dos dados atuais.

Crie uma função definida pelo usuário para criar os novos valores e um acionador para preencher o campo quando os dados forem adicionados, para que você não tenha muito mais sobrecarga na manutenção do campo.

A combinação de dois ou três de seus campos colocaria você abaixo do limite de 16.

Você pode usar um gatilho para insert/ update. Faça um agrupamento selecionado por suas colunas com uma cláusula de having count(*) > 1. Se isso voltar não vazio, reverta.

Aqui está o que eu faria. Eu criaria um gatilho AFTER para INSERT, UPDATE que executa uma ROW_NUMBER ()função e particiona todas as 18 colunas exclusivas. Se o número máximo de linhas for maior que um, faça a ROLLBACK.