DevMedia
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
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 como acessar este post

1) Torne-se um assinante MVP e por apenas R$ 69,90 por mês você terá acesso completo a todos os posts. Assinar MVP

2) Adquira Créditos: comprando R$ 180,00 em créditos esse post custará R$ 1,20. Comprar Créditos

post favorito     comentários

artigo SQL Magazine 30 - Char x Varchar

Artigo da Revista SQL Magazine -Edição 30.

[fechar]

Você não gostou da qualidade deste conteúdo?

(opcional) Você poderia comentar o que não lhe agradou?

Confirmo meu voto negativo
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’,

   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)

         select rtrim(convert(char(6),

            @a))+left(productname,14) fixo

            from northwind..products

         set @a = @a + 1

   end

set nocount off

go"

A exibição deste artigo foi interrompida

Este post está disponível para assinantes MVP.



Eduardo Morelli (www.tmorelli.com.br) é autor dos livros SQL Server 2000 Fundamental (2001) e Oracle 9i Fundamental (2002), ambos publicados pela Editora Érica (www.editoraerica.com.br). Além de trabalhar em diversos clientes como [...]

O que você achou deste post?
Publicidade
Serviços

Mais posts