Atenção: por essa edição ser muito antiga não há arquivo PDF para download. 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) ...
Os artigos dessa edição estão disponíveis somente através do formato HTML.
artigo SQL Magazine 30 - Char x Varchar
Artigo da Revista SQL Magazine -Edição 30.
Confira outros conteúdos:
Perguntas frequentes
Nossos casos de sucesso
Eu sabia pouquíssimas coisas de programação antes de começar a estudar com vocês, fui me especializando em várias áreas e ferramentas que tinham na plataforma, e com essa bagagem consegui um estágio logo no início do meu primeiro período na faculdade.
Estudo aqui na Dev desde o meio do ano passado!
Nesse período a Dev me ajudou a crescer muito aqui no trampo.
Fui o primeiro desenvolvedor contratado pela minha
empresa. Hoje eu lidero um time de desenvolvimento!
Minha meta é continuar estudando e praticando para ser um
Full-Stack Dev!
Economizei 3 meses para assinar a plataforma e sendo sincero valeu muito a pena, pois a plataforma é bem intuitiva e muuuuito didática a metodologia de ensino. Sinto que estou EVOLUINDO a cada dia. Muito obrigado!
Nossa! Plataforma maravilhosa. To amando o curso de desenvolvimento front-end, tinha coisas que eu ainda não tinha visto. A didática é do jeito que qualquer pessoa consegue aprender. Sério, to apaixonado, adorando demais.
Adquiri o curso de vocês e logo percebi que são os melhores do Brasil. É um passo a passo incrível. Só não aprende quem não quer. Foi o melhor investimento da minha vida!
Foi um dos melhores investimentos que já fiz na vida e tenho aprendido bastante com a plataforma. Vocês estão fazendo parte da minha jornada nesse mundo da programação, irei assinar meu contrato como programador graças a plataforma.
Wanderson Oliveira
Comprei a assinatura tem uma semana, aprendi mais do que 4 meses estudando outros cursos. Exercícios práticos que não tem como não aprender, estão de parabéns!
Obrigado DevMedia, nunca presenciei uma plataforma de ensino tão presente na vida acadêmica de seus alunos, parabéns!
Eduardo Dorneles
Aprendi React na plataforma da DevMedia há cerca de 1 ano e meio... Hoje estou há 1 ano empregado trabalhando 100% com React!
Adauto Junior
Já fiz alguns cursos na área e nenhum é tão bom quanto o de vocês. Estou aprendendo muito, muito obrigado por existirem. Estão de parabéns... Espero um dia conseguir um emprego na área.