Clique aqui para ler todos os artigos desta edição
Onde está o meu Índice?
por Mauro Sant’Anna
Suponha que você seja um bibliotecário na famosa biblioteca de Alexandria há dois mil anos e receba um novo manuscrito para armazenar. Você atribui a ele um número seqüencial, por exemplo 51788, guarda-o no escaninho correspondente ao número 51788 e incrementa esse número à espera do próximo documento. Os escaninhos tem todos o mesmo tamanho, ficam em longas prateleiras e são numerados em seqüência e sem intervalos. Observe que esse número não traz nenhuma informação sobre o documento, ele é apenas um artifício do mecanismo usado para armazenamento. Evidentemente, é facílimo localizar o manuscrito a partir de seu número, mas os usuários da biblioteca não conhecem esse número. Eles estão mais interessados em pesquisar os documentos por autor, título e assunto, as “chaves de pesquisa” usam uma terminologia mais moderna. Infelizmente, examinar todos os manuscritos seqüencialmente à procura de um certo título, autor ou assunto não é prático, dado o enorme trabalho envolvido. Como você resolve este problema? Simples, você pega três papiros pequenos de 8 cm por 5 cm (vamos chamá-los de cartões), escreve na parte superior de um deles o título, em outro o autor e no outro o assunto. No meio dos cartões, você escreve o número correspondente ao papiro (51788). Cada um desses cartões é colocado em um escaninho próprio na ordem alfabética correspondente. É claro que mantê-los em ordem alfabética dá um pouco de trabalho, mas é bem mais fácil que manusear os manuscritos.
Quando um usuário quiser pegar um manuscrito de acordo com seu título, ele pesquisará com facilidade nos cartões – que estão em ordem alfabética – e obterá o número do escaninho, com o qual localizará facilmente o manuscrito.
Esse esquema de organização de informações é chamado de “seqüencial indexado”. “Seqüencial” porque os dados são armazenados seqüencialmente na ordem em que vão chegando. “Indexado” porque mantemos índices – os cartões – para acelerar as pesquisas. Esse esquema é tão bom que é usado até hoje em bibliotecas no mundo todo. Na verdade, é tão incrivelmente bom que foi muito usado em informática para o acesso a bancos de dados. Nós o conhecemos pela sigla em inglês ISAM (“Indexed Sequencial Access Method”). Esse tipo de acesso é bem conhecido de quem programou com dBase, Clipper e COBOL. Pode existir alguma variação na construção dos índices: às vezes, as chaves são armazenadas seqüencialmente, outras vezes em uma “hash table”, eventualmente em árvores e, não raro, em uma mistura de várias técnicas. Mas continua sendo ISAM.
A natureza seguia calmamente seu curso quando inventaram o SQL no início da década de setenta. O SQL nasceu como uma linguagem de consulta e alterações de dados e trazia uma grande novidade: em vez de usar índices e chaves, ele se baseava em operações de conjuntos. Toda consulta trazia “conjuntos de resultados”, cópias de um pedaço da base obtidas a partir de um comando SQL, como, por exemplo, “SELECT Nome, Salário FROM Funcionários where Nome = ‘José’”. Foram definidas também operações de atualização com os comandos INSERT, UPDATE e DELETE, também atuando sobre “conjuntos”. Por exemplo, para apagar todos os funcionários chamados “João” faríamos “DELETE FROM Funcionários WHERE Nome = ‘João’”.
Observe que o SQL funciona muito bem sem que precisemos saber o que são chaves ou índices. Também não precisamos efetuar as tão comuns operações de varredura do tipo “while not EOF” que fazíamos em tabelas ISAM, pois os comandos atuam sobre um conjunto completo de dados.
O SQL é inegavelmente mais fácil de usar e muito mais prático do que ficar fazendo loops dentro de loops em tabelas ISAM. Os aplicativos passaram então a usar o SQL para acessar os dados e o ISAM tornou-se obsoleto. Viva o SQL, abaixo o ISAM.
Contudo, existem alguns “pequeninos” problemas no uso do SQL. Um deles consiste em atender aos usuários que desejam exibir dados em grids e listboxes e ficar paginando para cima e para baixo. Fazer isso com bancos SQL é sempre problemático; não existe nenhuma maneira de atingir a performance e a flexibilidade obtidas no ISAM.
O mais irônico é que os bancos de dados SQL usam ISAM internamente, já que, desde o tempo dos egípcios, o ISAM é a melhor forma de resolver os problemas de gerenciamento de bancos de dados.
Até poucos anos atrás, ainda havia servidores de bancos de dados não-SQL, mas os bancos SQL engoliram eles todos. Talvez no futuro, quando todos estivermos aposentados, alguma empresa lance uma grande novidade: bancos de dados “puros ISAM”.
