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
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’,
" [...] continue lendo...
