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.

Imagem

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. Comandos digitados no Query Analyzer para a criação da base de dados.

 

create database teste on primary

(name = ‘teste_dat’,

   filename = ‘c:\teste.mdf’, size = 12 GB,

   maxsize = 50 GB, filegrowth = 100 MB)

log on

(name = ‘teste_log’,

   filename = ‘c:\teste.ldf’,

   size = 100 MB, filegrowth = 10 MB)

go

alter database teste set recovery simple

go

 

 

Perceba que já criamos uma grande base (12 GB), suficiente para comportar as tabelas plenamente preenchidas. Este pré-dimensionamento evitará que, durante os processos de carga, existam expansões do arquivo físico (TESTE.MDF), que causem possíveis fragmentações em disco. Vale também frisar a escolha pelo Modelo de Recuperação (Recovery Model) Simple. Isto faz com que o registro de transações (Transaction Log) não precise ser copiado de tempos em tempos, mantendo o tamanho do arquivo físico sempre constante, neste caso, em 100 MB.

A Listagem 2 exibe a criação das tabelas, uma contendo a cadeia de caracteres com tamanho variável e outra fixo.

 

 

Listagem 2. Comandos digitados no Query Analyzer para a criação das tabelas.

 

use teste

create table variavel (id integer identity not null,

variavel varchar (200) not null)

go

 

create table fixa (id integer identity not null, fixo

char (200) not null)

go

 

As Listagens 3 e 4 contêm comandos para a primeira carga nas tabelas e criação de respectivos índices. Como bem lembrado no artigo de Blumm e Fornari, os índices devem ser criados depois das cargas. Assumimos a presença da tabela products na base Northwind. Perceba como garantimos o preenchimento de um décimo de cada linha concatenando ao contador os 14 primeiros caracteres do nome do produto.

 

 

Listagem 3. Carga da tabela VARIAVEL.

 

set nocount on

declare @a int

set @a = 1

while @a <= 100000

   begin

      insert variavel (variavel)

...

Quer ler esse conteúdo completo? Tenha acesso completo