A linguagem SQL é não procedimental, ou seja, nas sentenças se indica o que queremos conseguir e não como tem que fazer o intérprete para consegui-lo. Isto é pura teoria, pois na prática todos os gerenciadores de SQL têm que especificar seus próprios truques para otimizar o rendimento.

Portanto, muitas vezes não basta com especificar uma sentença SQL correta, e sim que além disso, há que indicar como tem que fazer se quisermos que o tempo de resposta seja o mínimo. Nesta seção, veremos como melhorar o tempo de resposta de nosso intérprete ante umas determinadas situações:

Design de tabelas

• Normalize as tabelas, pelo menos até a terceira forma normal, para garantir que não haja duplicidade de dados e aproveitar o máximo de armazenamento nas tabelas. Se tiver que desnormalizar alguma tabela pense na ocupação e no rendimento antes de proceder.
• Os primeiros campos de cada tabela devem ser aqueles campos requeridos e dentro dos requeridos primeiro se definem os de longitude fixa e depois os de longitude variável.
• Ajuste ao máximo o tamanho dos campos para não desperdiçar espaço.
• É normal deixar um campo de texto para observações nas tabelas. Se este campo for utilizado com pouca freqüência ou se for definido com grande tamanho, por via das dúvidas, é melhor criar uma nova tabela que contenha a chave primária da primeira e o campo para observações.

Gerenciamento e escolha dos índices

Os índices são campos escolhidos arbitrariamente pelo construtor do banco de dados que permitem a busca a partir de tal campo a uma velocidade notavelmente superior. Entretanto, esta vantagem se vê contra-arrestada pelo fato de ocupar muito mais memória (o dobro mais ou menos) e de requerer para sua inserção e atualização um tempo de processo superior.

Evidentemente, não podemos indexar todos os campos de uma tabela extensa já que dobramos o tamanho do banco de dados. Igualmente, tampouco serve muito indexar todos os campos em uma tabela pequena já que as seleções podem se efetuar rapidamente de qualquer forma.

Um caso em que os índices podem ser muito úteis é quando realizamos petições simultâneas sobre várias tabelas. Neste caso, o processo de seleção pode se acelerar sensivelmente se indexamos os campos que servem de nexo entre as duas tabelas.

Os índices podem ser contraproducentes se os introduzimos sobre campos triviais a partir dos quais não se realiza nenhum tipo de petição já que, além do problema de memória já mencionado, estamos lentificando outras tarefas do banco de dados como são a edição, inserção e eliminação. É por isso que vale a pena pensar duas vezes antes de indexar um campo que não serve de critério para buscas ou que é usado com muita freqüência por razões de manutenção.

Campos a Selecionar

• Na medida do possível há que evitar que as sentenças SQL estejam embebidas dentro do código da aplicação. É muito mais eficaz usar vistas ou procedimentos armazenados por que o gerenciador os salva compilados. Se se trata de uma sentença embebida o gerenciador deve compila-la antes de executa-la.
• Selecionar exclusivamente aqueles que se necessitem
• Não utilizar nunca SELECT * porque o gerenciador deve ler primeiro a estrutura da tabela antes de executar a sentença
• Se utilizar várias tabelas na consulta, especifique sempre a que tabela pertence cada campo, isso economizará tempo ao gerenciador de localizar a que tabela pertence o campo. Ao invés de SELECT Nome, Fatura FROM Clientes, Faturamento WHERE IdCliente = IdClienteFaturado, use: SELECT Clientes.Nome, Faturamento.Fatura WHERE Clientes.IdCliente = Faturamento.IdClienteFaturado.

Campos de Filtro

• Procuraremos escolher na cláusula WHERE aqueles campos que fazem parte da chave do arquivo pelo qual interrogamos. Ademais se especificarão na mesma ordem na qual estiverem definidas na chave.
• Interrogar sempre por campos que sejam chave.
• Se desejarmos interrogar por campos pertencentes a índices compostos é melhor utilizar todos os campos de todos os índices. Suponhamos que temos um índice formado pelo campo NOME e o campo SOBRENOME e outro índice formado pelo campo IDADE. A sentença WHERE NOME='Jose' AND SOBRENOME Like '%' AND IDADE = 20 seria melhor que WHERE NOME = 'Jose' AND IDADE = 20 porque o gerenciador, neste segundo caso, não pode usar o primeiro índice e ambas sentenças são equivalentes porque a condição SOBRENOME Like '%' devolveria todos os registros.

Ordem das Tabelas

Quando se utilizam várias tabelas dentro da consulta há que ter cuidado com a ordem empregada na cláusula FROM. Se desejarmos saber quantos alunos se matricularam no ano 1996 e escrevermos: FROM Alunos, Matriculas WHERE Aluno.IdAluno = Matriculas.IdAluno AND Matriculas.Ano = 1996 o gerenciador percorrerá todos os alunos para buscar suas matrículas e devolver as correspondentes. Se escrevermos FROM Matriculas, Alunos WHERE Matriculas.Ano = 1996 AND Matriculas.IdAluno = Alunos.IdAlunos, o gerenciador filtra as matrículas e depois seleciona os alunos, desta forma tem que percorrer menos registros.