Atenção: por essa edição ser muito antiga não há arquivo PDF para download.
Os artigos dessa edição estão disponíveis somente através do formato HTML.

Clique aqui para ler todos os artigos desta edição

Utilizando colunas calculadas na implementação de regras e otimização de performance

 

Segundo as regras de normalização, não devemos armazenar em uma coluna valores que podem ser obtidos por operações executadas sobre outras colunas. Esse tipo de procedimento pode "custar caro" por vários motivos:

·         Consome espaço em disco;

·         Exige que todas as aplicações que manipulam as colunas que fazem parte da fórmula estejam sincronizadas para atualizar também a coluna calculada;

·         Recuperar o resultado de uma fórmula do disco é um processo lento.

 

Pensando assim, não seria conveniente criar uma coluna col_C em uma tabela teste para armazenar o produto de duas outras colunas (col_A * col_B). Cabe aqui um questionamento: Como fazer para manter a mesma regra de cálculo em todas as aplicações, evitando-se que sejam utilizados diferentes critérios para obter col_C?

Existem três possibilidades:

1.      Armazenar a fórmula em uma stored procedure. A aplicação que necessitar de col_C será obrigada a executar a procedure;

2.      Armazenar a fórmula em uma função. A aplicação que necessitar de col_C será obrigada a executar a função;

3.      Armazenar a fórmula em uma coluna calculada. A coluna col_C será criada na tabela teste; para obter o resultado de col_C, basta efetuar um select na tabela;

 

Das três opções, a criação da coluna calculada é a que apresenta melhor custo-benefício e menor complexidade para implantação. Vamos proceder à criação da tabela teste, de modo que consigamos avaliar a implementação das três soluções propostas (ver Listagem 1).

 

Listagem 1. Script para criação da tabela teste.

use NorthWind

go

...

Quer ler esse conteúdo completo? Tenha acesso completo