SQL Server – A importância de utilizar corretamente os Data Types

Antes de falar dos tipos em SQL Server ou em qualquer banco ou linguagem, vamos definir duas coisas importantes para o artigo: “Eficiência e eficácia” e “Um bom sistema”.

Eficiência e Eficácia

Chiavenato nos diz o seguinte sobre eficiência e eficácia:

“À medida que o administrador se preocupa em fazer corretamente as coisas, ele está se voltando para a eficiência (melhor utilização dos recursos disponíveis). Porém, quando ele utiliza estes instrumentos fornecidos por aqueles que executam para avaliar o alcance dos resultados, isto é, para verificar se as coisas bem feitas são as que realmente deveriam ser feitas, então ele está se voltando para a eficácia (alcance dos objetivos através dos recursos disponíveis) (Chiavenato, 1994)”.

Em um linguajar menos administrativo:

Eficiência – melhor utilização dos recursos disponíveis
Eficácia – alcance dos objetivos através dos recursos disponíveis

Portanto:

Eficiência e eficácia representa, então, alcançar os objetivos extraindo o máximo possível dos recursos disponíveis.

A imagem abaixo representa a eficiência e a eficácia de uma forma mais visual:

Um Bom Sistema

Inicialmente, um sistema de informação é criado para atender objetivos específicos. Este é o primeiro critério de um bom sistema: Ele atende os objetivos para o qual foi projetado.

Porém, sabemos que recursos financeiro não é algo ilimitado. O grande limitador de qualquer projeto são justamente os recursos financeiros.

É justamente a limitação dos recursos financeiros que define qual tecnologia vai ser utilizada. Por exemplo:

Um sistema pode ser desenvolvidos utilizando-se PostGreSQL ou Oracle, porém, um fator é fundamental: O PostGreSql é gratuito o Oracle é Caro.

Se estivermos falando de uma empresa Pequena, existe uma tendência muito grande em adotar PostGreSQL. Se for uma empresa muito grande, provavelmente ela já possua Oracle.

Porém, mesmo que a empresa seja muito grande, por que gastar dinheiro desnecessariamente com Oracle, quando um PostGreSQL atende?

Portanto, podemos definir um bom sistema como : “Um sistema que atende os objetivos para o qual foi projetado pelo menor custo“.

SQL Server e os Tipos de Dados

Existem três coisas que afetam um Banco de Dados: O número de linhas das tabelas, o Tamanho (em bytes) das tabelas e o número de linhas contidas em uma página.

Individualmente, estas três características não dizem muita coisa. Devem sempre ser trabalhadas juntas pelo analista de sistema no momento da modelagem dos dados.

O Número de linhas das tabelas

Isso é inerente ao processo organizacional. O Número de linhas nas tabelas vai refletir o processo operacional e a forma como os processos foram modelados.

Uma modelagem inadequada pode forçar um volume desnecessariamente grande de linhas, porém, isto não é absolutamente errado. Se o número de linhas for grande mais o tamanho da tabela for pequeno e o número de linhas na página for grande, você consegue um bom desempenho.

O tamanho da tabela em bytes

Tabelas muito grande tendem a ser problemas no momento de se realizar pesquisas, mais até do que o número de linhas.

Um bom modelo de dados evita a criação de estruturas que contenham, proporcionalmente, volumes absurdos de bytes.

Número de linhas contidas em uma página

Esta é uma característica importante, pois é fundamental para a performance. A maioria dos bancos de dados relacionais trabalha com paginação, o que agiliza a alocação de blocos de dados.

Registros com muitos bytes tendem a minimizar a ocupação da página, o que faz com que poucos registros sejam alocados em uma página.

Registros com poucos bytes tendem a maximizar a ocupação da página, o que faz com que muitos registros sejam alocados em uma página.

E o que os Data Types tem a ver com isso?

Tudo…

A escolha dos Data Types adequados é fundamental para a otimização dos recursos utilizados (memória, processamento, armazenamento, rede).

vamos a um exemplo simples. Observe o cenário abaixo:

Uma modelo de dados definiu uma estrutura única de situação para todos os registros do sistema, identificando 60 situações possíveis. Para isso criou a tabela conforme abaixo:

Create Table Situacao
(SituacaoID  Int
,Descricao   Varchar(30));

Observe que o tipo Int permite armazenar, em números positivos, até 2.147.483.647 registros e irá ocupar 4 bytes.

Como a tabela irá conter 60 situações e considerando que a descrição terá em média 20 bytes, temos um espaço total de 1.440 bytes de armazenamento.

Bom, vamos criar a mesma tabela de uma maneira mais adequada, usando o Data Type que mais se adequa a necessidade no conceito de eficiência e eficácia:

Create Table Situacao
(SituacaoID  TinyInt
,Descricao   Varchar(30));

Observe agora que o tipo TinyInt permite armazenar até 255 registros, mais do que o necessário para as situações previstas.

Considerando os mesmos parâmetros e que o TinyInt ocupa 1 byte, temos agora um total de 1.260 Bytes, o que representa uma economia de 180 bytes ou 12,5%.

É ai que entra o argumento que mais me incomoda: “O ganho é irrelevante para eu me preocupar com isto“.

Imaginemos o seguinte cenário: Uma tabela de transações que recebe 1 milhão de registros por mês e que possua uma chave estrangeira obrigatória para a tabela situação.

para você criar esta chave estrangeira, o campo “SituacaoID” na tabela de transação vai precisar ser do mesmo tipo existente na tabela “Situacao”.

Caso a tabela “Situacao” seja Int, você está ocupando 3 bytes a mais desnecessariamente, o que representa 3 milhões de bytes a mais por mês e 36 milhões a mais em um ano.

Além do mais, imagine que esta tabela possua outros 4 campos na mesma Situação (que poderiam ser TinyInt mas são Int). Isso representaria 15 milhões de bytes a mais por mês e 144 milhões de bytes a mais por ano.

Outra característica interessante: São 3 bytes a mais no tamanho da linha, o que minimiza a utilização das páginas de dados, afetando a eficiência no armazenamento.

Imagine outro cenário: Um índice precisa ser criado neste campo. Isso significa que o índice vai ficar maior do que precisaria ser, ocupando 3 bytes a mais por registro indexado.

Agora, replique este erro em centenas de tabelas e índices e você vai perceber que está desperdiçando MUITO recurso computacional.

Os campos de Data

Um exemplo bem interessante é a Utilização do Tipo DateTime para tudo. Este tipo ocupa 8 bytes enquanto o tipo Date ocupa 3 bytes. Então, Fica a pergunta: Você realmente precisa saber a Hora, o Minuto, o Segundo e o milésimo de segundo em uma data de nascimento?

A diferença de 5 bytes entre Date e DateTime faz com que a utilização desses recursos tenham que ser muito bem pensada.

Você realmente precisa dos milésimos de segundo ou somente os segundos são suficientes? Se somente os segundos forem suficientes, você pode utilizar o SmallDateTime que irá ocupar 4 bytes ao invés de 8.

Se você precisar somente da hora, você pode usar o Time ao Invés do DateTime e economizará 4 bytes.

Mas, e a aplicação…

Além do banco de dados, a aplicação também sofre com este problema. Imagine a tabela situação, criada com Int ao invés de TinyInt, quando o programador for declará-la, ele irá utilizar o tipo Int e não o TinyInt, o que representa um consumo maior de memória.

Agora, coloque essa aplicação na WEB sendo acessada por 100 mil usuários e teremos 300 mil bytes de memória desperdiçada. Imagine que esse erro existe em centenas de tabelas que serão utilizadas em dezenas de páginas acessadas por centenas de usuários e tenha uma ideia do tamanho da memória do servidor que será desperdiçada.

Exercício Prático: Faça um cálculo nos seus sistemas e veja o quanto você está desperdiçando de espaço. Depois multiplique isso pelo custo de armazenamento e das memórias e veja o tamanho do prejuízo financeiro. Você pode se surpreender.

O BUG do PSY

Quem não se lembra do “Bug do PSY” (Gangnan Style exige alteração no algoritimo do Youtube). O Youtube usava o Int para fazer o contador e um vídeo do PSY extrapolou essa quantidade.

Na época muita gente questionou a demora para alterar o contador: “É só mudar de Int para BigInt“, era o argumento da maioria.

NÃO É SÓ MUDAR. O BigInt ocupa 8 Bytes e o Int ocupa 4. Cada 1 bilhão de vídeos representaria 4 bilhões de bytes a mais no banco de dados.

Além disso, esses 4 bytes a mais refletiriam na aplicação, que precisaria mais memória para funcionar.

Isso sem contar o fato que somente um vídeo em mais de 10 anos conseguiu estourar o contador, então, a pergunta que fica é: Você, como analista, mudaria o tipo para BigInt? Ou pensaria em uma solução mais criativa para não desperdiçar este espaço todo?

Você acha que o Google (com toda sua fortuna) não está preocupada com meros gigas a mais, é isso? Se você acha que não então leia a noticia no link “Com mais de 1 bilhão de usuários youtube nao dá lucro para o google”

Mesmo o google, com todo o capital que possui, não deve estar muito interessado em desperdiçar dinheiro.

Pense em uma solução criativa para resolver o problema do “Bug do PSY” da forma mais econômica possível (Esse é um bom exercício para testar os conceitos deste artigo).

Conclusão

A disponibilidade dos recursos computacionais deixou os desenvolvedores preguiçosos. Nos primórdios da computação, quando recursos como memória e discos eram algo raro, os desenvolvedores de sistemas eram extremamente competentes em otimizar seus códigos ao máximo possível, extraindo o máximo das máquinas.

Certa vez, tentando demonstrar a um desenvolver da importância deste recurso, ele me disse o seguinte: “O tempo de se preocupar com isso já passou. Hoje 50MB de disco não representa nada“.

Representa sim, e representa muito. A economicidade dos sistemas é fundamental para a sustentabilidade dos sistemas … e para a vida do planeta (memória e disco são construídos com recursos naturais).

Não é por que temos o recurso abundante que vamos desperdiçá-lo. É justamente essa visão que coloca o planeta em risco ao elevar o aquecimento global. Não vamos trazer essa visão também para o TI.

Além do mais, o que mais me apaixona na programação é o desafio de sempre me superar, fazendo códigos cada vez mais eficientes.

Um bom analista: É aquele que consegue elaborar modelos de dados que atendam os requisitos do negócio ocupando o menor espaço possível e com o melhor desempenho possível.

Um bom programador: É aquele atende os requisitos utilizando o mínimo possível dos recursos computacionais.

São características que tornam os sistemas eficientes e eficazes. O servidor agradece… a empresa agradece… a natureza agradece…