A biblioteca de componentes visuais (VCL) disponibiliza para os programadores várias formas diferentes de acesso à banco de dados. Os componentes principais para esta tarefa são a Table e a Query e como veremos, a seguir, as diferenças entre o acesso a dados com estes dois objetos existem e devem ser respeitadas para que tiremos o melhor rendimento de nossas aplicações.
Para acesso a bancos de dados locais como Paradox ou DBase, sem dúvida o componente Table apresenta uma performance superior ao componente Query. Porém, para o ambiente Cliente/Servidor, esta afirmativa não é assim tão simples, ou seja, a velocidade no acesso a dados não melhora simplesmente por utilizarmos um componente Query ou um componente Table, mas sim pelo modo através do qual estes componentes obtém os registros do banco de dados. Trabalhar com um LIVE RESULT SET é certamente a forma mais lenta de acessar registros. Este modo de acesso permite que o usuário possa inserir, alterar e excluir registros no banco de dados, enquanto um NÃO-LIVE RESULT SET acessa os registros somente para leitura, obtendo, portanto, um tempo de resposta bem menor na conexão. Para trabalhar com uma Table no modo LIVE RESULT SET basta manter a propriedade ReadOnly igual a False. Para trabalhar com uma Query no modo LIVE RESULT SET teremos que modificar a propriedade RequestLive para True.
Para compararmos a performance das diferentes formas de acesso, utilizaremos uma aplicação exemplo composta de dois formulários e um datamodule. Esta aplicação irá acessar uma tabela em um banco de dados InterBase, e para monitorarmos os acessos que nossa aplicação fará ao banco de dados utilizaremos um aplicativo chamado SQLMonitor que se encontra no menu Database/SqlMonitor no Delphi, que serve para visualizarmos os acessos ao banco de dados que a aplicação realiza, mesmo depois de compilada. O SQLMonitor deverá ser carregado antes da aplicação. A primeira tela é um cadastro de clientes que possui uma Table e uma Query, ambas utilizando LIVE RESULT SET. Existe ainda um radio group que modifica o componente de acesso a dados e um botão que efetua a conexão do objeto escolhido com o banco. Ao executarmos a aplicação e clicarmos neste botão veremos no SQLMonitor que a conexão neste modo é igual tanto para a Table quanto para a Query, ou seja, são necessários cinco acessos ao banco para que seja efetuada a validação da sua operação. Esta validação testa se a instrução está correta e se o usuário tem permissão para executá-la. Isto será feito sempre no primeiro acesso, após a criação do componente (a criação dos componentes quando não está explicita no código, é feita no onCreate do formulário).
Para evitar esta validação e diminuir, portanto, o número de acessos ao banco de dados, teremos que encontrar uma forma de respeitar a necessidade do sistema de inserir, alterar e excluir registros de uma determinada tabela sem utilizar um LIVE RESULT SET, que prejudicaria a performance do sistema.
Para isso poderemos utilizar apenas o componente Query, bastando realizar uma pequena modificação: devemos alterar sua propriedade CachedUpdates para True e manter a propriedade Request Live em False.
Deveremos incluir no segundo formulário um componente UpdateSQL e preencher suas propriedades Insert SQL, ModifySQL e DeleteSQL conforme nossa aplicação exemplo.Após isso, devemos preencher a propriedade Update Object da nossa Query com o nome do objeto Update SQL que acabamos de criar. Feito isso basta lembrarmos que enquanto utilizarmos a propriedade Cached Updates como True, os registros inseridos em nossa tabela somente serão transferidos para o banco de dados quando utilizarmos o método ApplyUpdates do componente Query.
O resultado desta modificação é que ao rodarmos nossa aplicação, ela realiza apenas um acesso ao banco, ao invés dos cinco acessos da forma anterior, o que significa uma redução de 400% na quantidade de acessos do componente para a conexão com o banco.
Ressaltamos que após feita a conexão do componente (Table ou Query) com o banco de dados, tanto o LIVE RESULT SET quanto o NÃO-LIVE RESULT SET apresentam o mesmo número de acessos, o que significa que se a aplicação cria a Table ou a Query poucas vezes ao longo de um processo, alterar a estratégia de acesso lhe trará poucas vantagens, pois a única mudança perceptível será uma espera menor na primeira vez em que uma tabela for acessada. No entanto, se sua aplicação possui processos que criam tables ou querys repetidamente, a utilização de Querys com CachedUpdates e objetos UpdateSQL trará uma grande melhoria na performance final de sua aplicação.
