artigo SQL Magazine 30 - Char x Varchar

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

Char x Varchar:

estendendo a discussão

Na edição 28, Cesar Blumm e Miguel Fornari levantaram cinco interessantes dúvidas freqüentes sobre bancos de dados. A primeira delas, uma comparação entre os tipos de dados Char e Varchar, deixou claro que a escolha do segundo seria em alguns casos vantajosa em relação ao primeiro. Mostraremos nesta matéria algumas situações em que o uso de Varchar é mais vantajoso.

Espera-se que o leitor já tenha alguma vivência em SQL Server, conhecendo suas principais ferramentas tais como Query Analyzer ou Enterprise Manager, além de, claro, ter lido a matéria de Cesar e Miguel. Acreditamos firmemente que resultados semelhantes aos obtidos nos testes aqui realizados com SQL Server seriam também alcançados em Oracle, PostgreSQL, ou qualquer outro SGBDR.

Fundamentos

Inicialmente, vale frisar que independente do fato da escolha do tipo de tamanho variável geralmente apresentar melhores resultados do que o tipo de tamanho fixo, existem situações em que não há dúvidas quanto à melhor escolha. Por exemplo, imagine uma tabela de funcionários contendo um campo denominado UF (Unidade da Federação). Ora, se já sabemos de antemão que todas as linhas terão neste campo dois e apenas dois caracteres, porque introduzir o ônus do tamanho variável? Vale frisar que, para o SGBDR, o fato de um campo ter tamanho variável ao invés de fixo incorre em mais um trabalho, já que se deve registrar de alguma forma o tamanho corrente da cadeia de caracteres de tamanho variável.

Isso vale para qualquer campo de caracteres, cujo preenchimento pleno ou não, seja conhecido previamente. Tenha o campo um, dez ou oito mil caracteres, caso soubéssemos que estará completamente preenchido, vale a pena utilizar o tamanho fixo.

Outro aspecto não comentado no artigo de Blumm e Fornari contempla a fragmentação dos índices envolvendo as cadeias de caracteres. A seguir, vamos provar que, dependendo do nível de atualizações em uma tabela, o nível de fragmentação dos índices associados prejudica tanto os tempos de resposta quanto os custos das consultas sobre a tabela.

Basicamente, montamos o seguinte experimento:

1. Criam-se duas tabelas, FIXA e VARIAVEL, ambas contendo grandes cadeias, porém uma utilizando o campo CHAR e outra o VARCHAR;

2. Realizam-se cargas massivas que provoquem a ocupação de um décimo de cada string;

3. Para viabilizar consultas, constroem-se índices e verificam- se custo e tempo de resposta de uma consulta envolvendo as cadeias. Como era de se esperar, e em conformidade com os testes realizados por Blumm e Fornari, o tipo variável vence amplamente, já que há muito menos páginas (ler Nota 1) a serem varridas;

4. Nova carga acontece, agora aumentando o nível de preenchimento das páginas de 10 para 90%! E, como imaginávamos, a consulta sobre o campo variável perde da consulta sobre o campo fixo.

Nota 1. Página

Consiste na menor unidade de transferência entre disco e memória.

Possui tamanho fixo, 8Kb, e nenhuma linha pode extrapolar seus

limites.

Carga inicial

Ativando o Query Analyzer e abrindo-se uma conexão, observe os comandos presentes na Listagem 1 responsáveis pela criação da base.

Listagem 1"

A exibição deste artigo foi interrompida.

  Este é um post disponível para assinantes MVP

Este post também está disponível para assinantes da SQL Magazine DIGITAL
ou para quem possui Créditos DevMedia.  Clique aqui para saber mais!

Saiba como acessar este post através de Créditos DevMedia:

Assinatura de Créditos – Aqui este post custa R$ 1,47
Com esse plano você compra R$ 180,00 em créditos e ganha, em média, 80% de desconto no preço do post.  
Assine agora

Plano ocasional - Aqui este post custa: R$ 1,96 (assinante) ou R$ 2,45 (não-assinante)
Você compra um mínimo de R$ 60,00 em créditos e ganha, em média, 50% de desconto no preço do post.  
Compre agora

Plano conveniência – Neste plano este post custa R$ 4,90
Neste plano você compra somente um post, pagando seu preço sem desconto.  
Compre agora