Uma coluna computada tem seu valor calculado dinamicamente, através de uma expressão, que pode ou não referenciar outras colunas da mesma tabela. Ou seja, um comando DML não poderia definir o valor de uma coluna computada. Para definir uma coluna como computada deve se utilizar a palavra chave PERSISTED.
Qual é o ganho em se utilizar uma coluna com essa definição?
Eu vejo 2:
* Performance (como demostro abaixo), uma coluna que mantem o valor calculado “persistido” não precisa calcular em tempo de execução; É possível definir índices baseados em uma coluna computada.
* Centralização da regra, por mais simples que possa parecer, em um sistema de muitas especificações, um simples cálculo pode se tornar uma dor de cabeça (claro que a mesma regra pode estar na aplicação, mas nesse caso o ganho de performance vai ser menor, dependendo do caso).

Vamos criar um exemplo:

CREATE TABLE #Produto (
Nome VARCHAR(200),
ValorUnitario DECIMAL(10, 2),
PorcentagemDesconto DECIMAL(10, 3),
Quantidade INT,
SubTotal AS ((ValorUnitario * Quantidade) - (ValorUnitario * PorcentagemDesconto / 100) * Quantidade) --PERSISTED
);

INSERT INTO #Produto (Nome, ValorUnitario, PorcentagemDesconto, Quantidade) VALUES('Produto 1', 100.10, 10, 10);
INSERT INTO #Produto (Nome, ValorUnitario, PorcentagemDesconto, Quantidade) VALUES('Produto 2', 350.41, 6.9, 5);
INSERT INTO #Produto (Nome, ValorUnitario, PorcentagemDesconto, Quantidade) VALUES('Produto 3', 90.75, 0.1, 10);

Primeiro criei uma tabela temporária com algumas colunas, a principal delas é SubTotal, ela devolverá o calculo do valor do produto, nesse primeiro momento não defini a coluna SubTotal como PERSISTED (está comentada); E inseri alguns produtos.

Se executarmos um select simples como este(lembre de visualizar o plano de execução: Ctrl + L), teremos o seguinte resultado:

SELECT * FROM #Produto2;

planoExecucao1

Você pode ver claramente que existe um operador adicional quando não se tem colunas persistentes. Isso ocorre quando o valor da coluna é calculado em tempo de execução. Para ser mais preciso, vamos ver o custo final da operação de leitura como segue:

custo

Bom, agora temos uma forma de mensurar o quanto podemos ganhar com uma coluna PERSISTED. Vamos alterar a coluna da tabela temporária de produto para PERSISTED.

ALTER TABLE #Produto
DROP COLUMN SubTotal;

ALTER TABLE #Produto
ADD SubTotal AS ((ValorUnitario * Quantidade) - (ValorUnitario * PorcentagemDesconto / 100) * Quantidade) PERSISTED;

Se visualizarmos novamente o plano de execução com o mesmo select executado anteriormente:
planoExecucao3

Vê-se claramente, que o custo é menor em comparação com o valor de coluna não-persistente. Quando o cálculo é complexo, uma coluna persistente melhora o desempenho de pré-calculo dos valores de colunas calculadas. Claro que a diferença do custo final foi baixa, mas o calculo que fiz também é muito simples.

Até a próxima pessoal!