Diferenças entre índices Codebase e TOPCONN

Conceito de índices permanentes e diferenças das RDDs

Na RDD TOPCONN, não temos o conceito de criação de índice temporário, apenas índice permanente. Um índice permanente é criado fisicamente no banco de dados relacional utilizado, através do TOTVS | DBAccess, onde devemos especificar um ou mais campos para compor a chave/expressão de índice.

Quando utilizamos Codebase/DBF, podemos especificar como campos de chave de índice , como por exemplo as funções Str(), DToS() e SubStr(), entre outras funções suportadas de modo nativo pela aplicação provedora de acesso, no caso ADS Local e/ou ADS Server.

Ao utilizar um banco de dados relacional SGBD, através do TOTVS | DBAccess, devemos especificar uma expressão de chave que sempre retorne uma valor caractere, e as únicas funções permitidas para adequações do tipo de dado no AdvPL para essas expressões de índice são: Str(), DToS().

Funcionamento interno

A expressão utilizada para criar um índice permanente em AdvPL, por exemplo: CPOC+DToS(CPOD) + Str(CPON,10), quando utilizamos a RDD TOPCONN, será ajustada para o banco de dados relacional utilizado para uma expressão contendo apenas a lista de campos desejada, na sequência em que foi especificada, e as funções DToS() e Str() não são passadas ao banco de dados, pois não existe a necessidade de conversão de dados para o banco.

Um campo do tipo "D" Data, é tratado pelo TOTVS | DBAccess e gravado na tabela em questão como um campo "C" Caractere, de 8 bytes, no formato AAAAMMDD, e os números são gravados em um campo Double.

Quebra de compatibilidade com CodeBase/DBF

Os bancos de dados relacionais, em sua grande maioria, senão todos, suportam apenas a criação de índices onde sejam especificados campos físicos da base de dados. Não são suportadas funções de conversão ou transformação de dados na criação de índice, como por exemplo SubString(), Left(), entre outras. Embora alguns bancos de dados permitam a criação de colunas calculadas, as mesmas são virtuais, isto é, não existem fisicamente na tabela, e também não é permitido o uso de colunas virtuais para a criação de índices.

Entendemos que a RDD CodeBase/DBF, onde originalmente foi desenvolvido o ERP, nos dava certa flexibilidade ao permitir operações como estas, porém, a um custo de processamento mais alto, pois para cada inserção ou alteração, a RDD tem que executar funções de conversão e concatenação de string para atualização dos índices que usam este recurso.

Desta forma, para manter o suporte a todos os índices permanentes, criados a partir de resultados de expressões, nas versões anteriores do ERP, teríamos um custo muito alto de complexidade, performance e duplicidade de informações nas tabelas. Seria necessário criar colunas físicas nas tabelas, transparentes ao usuário, para manter copias em duplicidade de partes de colunas agrupadas, com gatilhos de banco de dados disparados internamente em operações de insert e update, um mecanismo relativamente complexo de se manter, instável para dar manutenção e custoso em performance para o banco de dados. 

Partido da premissa que, se uma determinada informação deve ser indexada para busca, ela deve ser uma informação que ocupa exclusivamente um campo físico da base de dados, são evitadas as operações constantes de concatenação e desmembramento de uma informação agrupada, colocando cada parte da informação em seu devido espaço (campo) definido, mesmo com o impacto gerado para alterar as aplicações que usavam esses tipos de índices, os ganhos obtidos em organização e performance foram muito significativos.