Eu tenho uma tabela, como a seguinte. Vamos chamá-lo Fools
.
ID do Tolo | Valor tolo | IsActiveFoolValue |
---|---|---|
1 | Ultra tolo | 0 |
1 | Super tolo | 1 |
2 | Muito tolo | 1 |
Uma regra de negócio é que para cada FoolID
, só podemos IsActiveFoolValue
estar 1
em uma linha. Quero algum tipo de chave ou restrição para impor isso. No entanto, que eu saiba, chaves e restrições não podem fazer isso. A única ferramenta é um índice exclusivo como
CREATE UNIQUE NONCLUSTERED INDEX OnlyOneActiveFoolValuePerFoolId
ON Fools(FoolID)
WHERE IsActiveFoolValue = 1
isso é considerado um antipadrão? Os índices não devem ser restrições. Eles deveriam ser ferramentas de desempenho. As restrições devem ser impostas por chaves, restrições e talvez gatilhos. Se for considerado um antipadrão, que desvantagens traz e quais alternativas existem?
Estou assumindo o SQL Server 2019, porque alguns recursos de índices filtrados exclusivos não existiam em versões muito antigas e quero manter minhas opções abertas para quaisquer alternativas modernas.
Eles não são considerados um antipadrão , mas são, até certo ponto, uma desnormalização .
De acordo com as regras muito estritas da 6ª Forma Normal, você realmente deve retirar essa
bit
coluna e, em vez disso, criar uma tabela separada.Mas um índice exclusivo filtrado faz essencialmente a mesma coisa, sem muitos clichês. É uma maneira comum de impor exclusividade em parte de uma tabela. Você não deve achar que isso é problemático, é uma maneira bastante padrão de lidar com isso e não é pior do que ter colunas anuláveis.
Além disso, não concordo com "Os índices não deveriam ser restrições. Eles deveriam ser ferramentas de desempenho". Você não pode simplesmente adicionar uma restrição exclusiva à tabela para desempenho; você precisa saber se os dados estarão em conformidade. Um índice exclusivo no final do dia é uma restrição, porque gerará um erro em uma duplicata.
E elas são, na verdade, muito melhores em muitas situações do que uma simples restrição única, porque podem ter
INCLUDE
colunas, para que possam funcionar como ambas ao mesmo tempo.Por outro lado, seu exemplo específico provavelmente deveria ter sido implementado usando Tabelas Temporais ou algum recurso semelhante.
Um uso mais realista do que uma tabela de tolos seria um certo estilo de tabela com linhas versionadas, onde a linha atual é marcada. É claro que pode haver apenas uma linha atual e é necessário que haja acesso rápido e indexado a ela.
Eu acho que é possível abusar dos índices de alguma forma, mas usar um índice exclusivo para impor a exclusividade dificilmente pode ser um abuso.
O exemplo é um pouco estranho. Você tem o FoolID, que eu esperaria ser a chave primária da tabela. Torná-la uma espécie de chave primária filtrada não parece certo.
Usar um índice filtrado para garantir que algo seja único em um subconjunto de linhas é adequado. Algo como garantir que a combinação de Name e ParentID seja única, mas apenas onde IsActive=1 possa fazer sentido. Dessa forma, você pode excluir linhas de forma reversível, mas permitir que um item com o mesmo nome seja recriado.
Há algumas coisas a serem observadas. Tomando seu exemplo, o índice filtrado não pode ser usado para estas consultas:
Você precisa ter cuidado para sempre usar IsActiveFoolValue=1 se quiser aproveitar as vantagens do índice no FoolID. Ou talvez você precise ter um índice extra no FoolID que não seja filtrado e tenha sobrecarga extra.
Pode haver opções alternativas que você possa considerar, mas não acho que haja algo inerentemente errado em usar um índice filtrado exclusivo.