Clique aqui para ler esse artigo em PDF.imagem_pdf.jpg

 

capaSQL28.JPG

 

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

 

Dúvidas frequentes sobre Banco de Dados 

Cesar Blumm e Miguel Rodrigues Fornari

 

SGBDs são utilizados há mais de trinta anos por diversas empresas. Ao longo deste tempo de uso, diversas  dúvidas tornaram-se comuns, por exemplo, há diferença na utilização de VARCHAR e CHAR? Uma delas será mais rápida? De tão comuns, é fácil encontrar em manuais e livros da área as respostas. Mas, será que estas respostas já não estão ultrapassadas frente ao avanço de software e hardware?

Neste artigo nós procuramos verificar se algumas respostas, frente à evolução da tecnologia, ainda são verdadeiras, ou se devem ser alteradas. As perguntas analisadas foram:

·       O que utilizar: VARCHAR ou CHAR?

·       A existência de índices ajuda na execução de um ORDER BY?

·       Deve-se desligar os índices durante cargas de dados em uma tabela?

·       A ordem das tabelas na cláusula FROM altera o tempo de resposta?

·       É interessante manter as tabelas ordenadas no disco?

 

Para responder a cada uma destas cinco perguntas, um conjunto de testes foi realizado, medindo o tempo de resposta em três diferentes SGBDs: Oracle 10g (e às vezes 9i), MS SQL Server 2000 e Firebird 1.5.2. Todas as operações foram realizadas no mesmo servidor, ativando apenas um dos SGBDs por vez para evitar interferências. O servidor sempre esteve dedicado a realizar uma única consulta, sem sofrer interferência de usuários concorrentes. Os SGBDs estavam em sua configuração default, exceto quando registrado o contrário.

Etapas no processamento de uma consulta

Antes de apresentarmos nossas respostas às perguntas, é importante explicar, mesmo que brevemente, como funciona o processamento de um consulta. A Figura 1 ilustra o processo.

 

image001.jpg

Figura 1. Etapas no processamento de uma consulta.

 

O usuário submete uma consulta em SQL. A primeira etapa, realizada pelo analisador, verifica a correção da consulta e a transforma em uma árvore de operações básicas, mantida internamente em uma estrutura de dados específica. Se houver erros, o processo é interrompido e o erro retornado ao usuário. Na segunda etapa, o otimizador de consultas escolhe a melhor seqüência para realizar as operações básicas e, entre os algoritmos possíveis para uma determinada operação, o melhor deles. A ordem de execução das operações e o algoritmo selecionado para cada uma delas compõem o plano de consulta que, enfim, é realizado pelo engine do SGBD. Finalmente, a resposta da consulta pode ser enviada ao usuário.

Neste processo, o otimizador desempenha o papel central. Há dois tipos de otimizações:

·         otimização baseada em regras heurísticas. Estas regras estão incorporadas ao Oracle. Em geral, elas produzem bons resultados, mas não há comprovação para garantir sua correção em todas as consultas;

·         otimização baseada em estatísticas. Nesta opção, o otimizador utiliza algumas fórmulas para calcular o custo (tempo de processamento + tempo de acesso aos dados em disco) de várias opções possíveis, e escolher a opção que apresentar o menor custo estimado. Os dados estatísticos, como número de linhas em cada tabela e número de diferentes valores de cada atributo são mantidos no dicionário de dados do SGBD.

 

Alguns SGBDs utilizam apenas um dos métodos, outros permitem que o DBA escolha o método de otimização que apresentar melhores resultados.

Tendo entendido como pode ser realizado o processamento de uma consulta, vamos agora analisar as perguntas formuladas no início desta matéria.

Pergunta 1: O que utilizar, VARCHAR ou CHAR?

A resposta mais comum afirma que atributos VARCHAR reduzem o espaço de armazenamento, porém atributos CHAR reduzem o tempo de resposta.

Para obter a resposta, foram criadas tabelas com diferentes tipos de atributos e número de registros. A estrutura básica das tabelas pode ser vista na Tabela 1. Há uma versão com todos os campos alfanuméricos mapeados para CHAR, e outra com eles mapeados para VARCHAR. A cardinalidade das tabelas variou entre 50.000 (tabela pequena), 300.000 (tabela média) e 900.000 (tabela grande) registros.

 

Coluna

Tipo

Chave

Alfanumérico(06)

CampoCheio

Alfanumérico(40)

CampoVazio

Alfanumérico(40)

CampoMeio

Alfanumérico(40)

CampoData

Data

CampoInteiro

Inteiro

CampoDecimal

Decimal(9,2)

Tabela 1. Definição das tabelas VARCHAR e CHAR.

 

A partir dos dados armazenados, foram realizadas diversas e repetidas vezes consultas por campos de índice, por campos comuns, utilizando a cláusula LIKE do SQL e por intervalo de registros, sempre aferindo os tempos para cada consulta realizada. Após as consultas, foram excluídas todas as linhas com o comando DELETE do SQL.

A primeira parte da resposta a esta pergunta afirma que tabelas com campo VARCHAR devem ocupar menos espaço em disco que as tabelas com campo CHAR.

Porém, no Firebird, é interessante notar que as tabelas CHAR estão ocupando menos espaço na área de dados do que as tabelas VARCHAR. Ou seja, a resposta esta errada! Já na área de índices, as duas ocupam o mesmo espaço.

 

Resultados obtidos

A Tabela 2 mostra o espaço ocupado em disco, em Kb, para manter as duas versões da tabela, no Firebird.  É interessante notar que as tabelas CHAR estão ocupando menos espaço na área de dados do que as tabelas VARCHAR.

 

Descrição

VARCHAR:

Tamanho em Kb

CHAR:

Tamanho em Kb

VARIAÇÃO:

Área de Dados

Tabela pequena

6.152

6.352

3,25%

Tabela média

...

Quer ler esse conteúdo completo? Tenha acesso completo