Prezados,

Eu trabalho no SERPRO e estou internalizando o i-Educar, e estou trabalhando para atualizar a aplicação para as versões mais novas do PostgreSQL. Muitas consultas e stored procedures já não apresentavam problemas, mas o que eu tenho notado que são as coisas mais complicadas são os comparativos de like/ilike em campos numéricos.

Em algumas buscas na aplicação, é permitido preencher somente parte dos campos CEP, CNPJ e CPF. Essa busca por partes é realizada via like (ou, caso queira ignorar a diferença entre maiúsculas e minúsculas, ilike).

Esse tipo de comparativo era permitido no PostgreSQL até a versão 8.2, onde era feito um cast implícito do campo e então era feita a comparação. Porém, like/ilike são comparações muito custosas a nível de banco de dados. Por exemplo, nas versões mais novas do PostgreSQL, é possível se escrever a consulta explicitando o cast, na forma

  > SELECT cpf FROM fisica WHERE text(cpf) like '%207%';

assim fazendo o banco de dados converter todas as linhas nessa coluna para text, e então a comparação via like, assim aumentando consideravelmente o tempo de cada consulta.

Uma alternativa para esta situação seria a criação de um índice de expressões, que funciona como um índice convencional no banco de dados, mas para uma expressão já aplicada nesta coluna. Isto diminui muito o custo da consulta, mas aumenta o custo das inserções.

Por último porém não menos importante, tem a forma que eu implementei para resolver os erros nas buscas do sistema, que envolve um comparativo com =. Ou seja, quando pesquisando CEP, CPF ou CNPJ, somente o número completo retorna algum resultado.

Agora para a minha pergunta: Qual seria a refatoração adequada para estas consultas? A criação de um índice de expressões é a que mantém a funcionalidade atual, mas eu sou a favor de uma abordagem mais simples. Como vocês fariam?

Se houver interesse, o que temos feito no SERPRO está disponível no repositório https://github.com/cmsz/ieducar , e eventualmente (quando tivermos uma migração estável do banco de dados) vamos gerar a pull request para o repositório principal.

Autor: Carlos Morais dos Santos