Performance começa na modelagem

Performance começa na modelagem

Tempo de leitura: 2 minutos

Desempenho começa na Modelagem.

Bom dia, Querido blog, tempo que não escrevo em você….rs. Hoje estou aqui apenas para falar  aos leitores sobre algumas pequenas dicas de performance  que as vezes passam despercebidos aos nossos olhos.

Vamos à análise.
Uma página de dados no SQL Server ocupa 8192 bytes, sendo 8060 bytes para os dados e o restante para o header da página. É correto afirmar que: criar um índice em uma coluna do tipo de dados inteiro que possui 2015 linhas vai ter uma página de dados completamente preenchida:

Calculo: Tipo de dados * Qtde de Linhas
Calculo: Int 4 Bytes * 2015 Linhas = 8060 bytes.

Thiago não estou entendendo aonde você que chegar!? Simples, meu caro blog! Será que preciso de uma coluna do tipo de dados int para a minha tabela. Desenvolvedores, analistas, programadores e estagiários é aqui que a gente entra.

Quando modelar alguma necessidade de negócio, sempre temos que nos atentar a que tipo de dados vamos usar e se é realmente necessário este  tipo de dados para determinada coluna. Já vi em muitos casos tabelas de domínio que apenas guarda poucos valores com o tipo de dados inteiro. Vamos a um exemplo:

YODA deve desenvolver um sistema de venda de produtos e foi especificado que os produtos a serem vendidos, seriam divididos em categorias. YODA criou o seguinte script para a tabela de categoria:

USE tempdb
go
IF OBJECT_ID(‘dbo.CategoriaProduto’) IS NOT NULL
BEGIN
DROP TABLE dbo.CategoriaProduto
END
CREATE TABLE dbo.CategoriaProduto (COD INT IDENTITY, DESCRICAO VARCHAR(50))

GO

Agora vem a pergunta! Até quantos registros posso armazenar em um tipo de dados inteiro? Segundo a definição do meu melhor amigo (Books On line), podemos armazenar -2^31 (-2,147,483,648) to 2^31-1 (2,147,483,647). Será que preciso armazenar todas estas categorias? Se tivermos apenas 50 ou ate 250 categorias, poderíamos usar o tipo de dados tinyint. Com isso apenas usaríamos um byte de armazenamento. Mas preciso mesmo me preocupar com esses detalhes? Será que essa diferença em bytes pode afetar minha performance ? A resposta é SIM!. O usuário final ou até mesmo o desenvolvedor não pode sentir essa perda, porém, isso para o SQL Server é extremamente importante. Uma das questões é: Tomando esse devido cuidado com tipo de dados você pode economizar espaço em disco e cache. Pode acreditar o buffer pool agradece.

Como o SQL Server ler os dados?

Todos nós sabemos que a leitura em memória é mais rápida do que a leitura em disco. O SQL Server também sabe! Quando uma query é enviada ao SQL Server ele verifica se os dados estão em memória (Buffer Pool), antes de verificar se os dados do disco. Como os dados estão em memória o SQL Server apenas realiza leitura lógica (Não Física). Thiago! E o que tudo isso tem a ver com o que foi escrito anteriormente? SIMPLES. Quanto menor for o tipo de dados usado em nossas colunas, menor a quantidade de espaço iremos armazenar e mais informações teremos dentro do buffer pool, sendo assim, diminuindo o acesso ao disco e aumentando a quantidade de informações em memória.

Pessoal modelar é uma tarefa muito importante, então, por favor. Prestem atenção. Estarei criado mais posts referente a estes assuntos futuramente.

 

3 comentários

  1. dieguitomelo disse:

    Olá Thiago,

    Muito interessante o artigo, mas eu fiquei com uma dúvida: Mesmo que o tipo INT pode armazenar até -2^31 (-2,147,483,648) to 2^31-1 (2,147,483,647), o byte só é registrado com o valor que está preenchido o campo?

    Grato.

    Diego

  2. alencardba disse:

    Primeiramente Obrigado.
    Cara,deixa eu ver se entendi sua pergunta! Você quer saber se o armazenamento dos bytes é feito apenas se a coluna está preenchida com valor? Se a pergunta é essa. A resposta é Não. O tipo de dados int é o que chamamos de Fixed Lenght. Mesmo que seja armazenado NULL você ocupa quatro bytes. Consegui responder sua pergunta?

Deixe uma resposta

%d blogueiros gostam disto: