Eu tenho uma tabela assim:
CREATE TABLE
dbo.DiscountBarcodeList
(
ID int NOT NULL IDENTITY
CONSTRAINT PK_DiscountBarcodeList
PRIMARY KEY CLUSTERED
, Discount int NOT NULL
CONSTRAINT FK_DiscountBarcodeList_Discount
FOREIGN KEY REFERENCES dbo.Discount (ID)
, CodeNumber int NOT NULL
, AssignedEntity int NULL
CONSTRAINT FK_DiscountBarcodeList_AssignedEntity
FOREIGN KEY REFERENCES dbo.Entity (ID)
ON DELETE SET NULL
, BarcodeID AS
CONVERT(
char(10)
, CAST(Discount AS binary(2)) + CAST(CodeNumber AS binary(3))
, 2)
, CONSTRAINT UQ_DiscountBarcodeList_DiscountCodeNumber
UNIQUE NONCLUSTERED
(
Discount ASC
, CodeNumber ASC
)
);
A tabela manterá CodeNumber
s alocados para Discount
s antecipadamente e atribuídos a Entity
s sob demanda. Embora não esteja no nível do banco de dados, os valores de Discount
e CodeNumber
serão limitados a 2 bytes e 3 bytes, respectivamente. Essas limitações, juntamente com a restrição exclusiva de , também (Discount, CodeNumber)
tornarão efetivamente os valores gerados únicos.BarcodeID
A forma como esta tabela deve ser usada é: o aplicativo passará um @BarcodeID
para procurar @Entity
e atribuir a ela. Se a pesquisa for bem-sucedida, as linhas Entity
serão definidas como @Entity
ou o aplicativo será notificado de que @BarcodeID
já foi usado, algo como isto:
BEGIN TRANSACTION;
UPDATE
SET
@OldEntity = Entity
, Entity = @Entity
WHERE
BarcodeID = @BarcodeID
;
IF @OldEntity IS NULL
BEGIN
COMMIT TRANSACTION;
... /* report success */
END
ELSE
BEGIN
ROLLBACK TRANSACTION;
... /* report failure */
END;
Agora eu gostaria de fazer BarcodeID
sargável. Como sei que a coluna terá apenas valores únicos, estou pensando em tornar o índice único, pois acho que isso pode tornar minha pesquisa mais eficiente. Por outro lado, estou preocupado que os valores gerados tenham que ser verificados quanto à exclusividade, o que é redundante aqui, uma vez que a exclusividade já está garantida.
É possível dizer de alguma forma se os benefícios, se houver, de um índice exclusivo em uma coluna computada superarão a provável sobrecarga da verificação de exclusividade (desnecessária neste caso)? Ou pelo menos é possível determinar isso para um cenário como o meu? Ou estou apenas pensando demais nisso?
É uma troca que só você pode realmente decidir.
Você já terá uma combinação de operadores Split-Sort-Collapse adicionada a quaisquer planos que sejam atualizados
Discount
ouCodeNumber
para evitar falsas violações transitórias de chave exclusiva. Adicionar um índice exclusivoBarcodeID
adicionará uma segunda combinação de operadores para atualizar os planos e um Eager Spool para conduzi-los. Também é possível que tais atualizações falhem com um erro se uma mesa de trabalho for necessária além dos limites do servidor. Essas são as principais desvantagens.Por outro lado, você obtém seu índice pesquisável e possivelmente informações melhores para o otimizador usar em geral. Você também tem uma garantia real de exclusividade, em vez de uma garantia implícita um pouco confusa.
Pessoalmente, eu provavelmente adicionaria o índice exclusivo e testaria a carga de trabalho para ver se o impacto no desempenho é suportável ou não.
Perguntas e respostas relacionadas: