Apesar de muitas pessoas utilizarem DataStore ao invés de cursor, a maioria não sabe quais são as vantagens e em qual situação o Cursor é melhor que a DataStore.
Para explicar as vantagens, primeiro temos que entender como os dois objetos funcionam.
A maioria dos cursores são composto de 4 comandos:
* Declare : Declara a variável e atribui o comando SQL que será executado, não fazendo acesso ao banco de dados.
* Open : Abre o cursor. Neste momento, é enviando um comando ao SGBD que executa a Query e carrega o resultado na memória do SGBD. Existem vários tipos de cursor e cada um funciona de uma forma, mas geralmente, é criada uma imagem do resultado na memória do SGBD.
* Fetch : Recupera o registro. Neste momento, é feito um acesso ao banco de dados, buscando o próximo registro na tabela temporária.
* Close : Fecha o cursor. Neste momento é feito um acesso ao SGBD para fechar e libera a memória que estava sendo utilizada pela tabela temporária.
Como vocês podem perceber, apenas o comando Declare não faz um acesso ao banco de dados. Como cada acesso ao banco de dados gera 2 tráfegos na rede (O envio do pacote com a solicitação e o recebimento do resultado), além de aumentar muita a utilização do processador do cliente, pois todos os pacotes de rede devem ser tratados (empacotados e desempacotados) pelo processador. A quantidade de acesso ao banco de dados degrada a performance do aplicativo, além de aumentar o trafego da rede, prejudicando a performance de outros aplicativos.
Outro ponto negativo do Cursor é que existem comando que fecham o cursor, por exemplo, na maioria dos SGBDs, se os comandos COMMIT e ROLLBACK forem executados com o cursor aberto, eles automaticamente fecham o curso, podendo gerar erro no aplicativo.
Já a DataStore funciona da seguinte forma:
* Quando você executa RETRIEVE na DataStore, o comando SQL é enviado ao banco de dados, processado e todos os dados são recuperados para a DataStore.
Essa solução possui uma perda de performance no primeiro momento, porque todos os dados são transferidos de uma única vez para o cliente, mas possui uma melhor performance se observarmos o processamento total, pois é feito apenas um acesso a base de dados (dois tráfegos de rede).
Outro problema da DataStore é que todos os dados são retornados para a memória da aplicação cliente, por isso, se a quantidade de dados recuperados for muito grande ou a memória do cliente for pouca, pode forçar a máquina a utilizar memória virtual (Paginação), gerando uma perda de performance no aplicativo e até mesmo cancelamento do processando por falta de memória.
Resumindo, os seguintes fatores influenciam a utilização de Cursor ou DataStore:
- Quantidade de usuários conectados ao SGBD (Quanto maior a quantidade de usuários conectados ao SGBD, maior a tendência de utilizar DataStore)
- Memória disponível no cliente (Quanto maior a quantidade memória, maior a tendência de utilizar datastore)
- Quantidade de Dados Recuperados (Quanto menor o número de colunas recuperado por registro, maior a tendência a utilizar a datastore)
- Qualidade da Rede (Quanto mais rápida a rede, maior a tendência a utilizar Cursor)
- Recursos disponíveis no servidor (Memória e processador) (Quanto maior os recurso disponíveis no servidor, maior a tendência a utilizar Cursor)
Sendo, que os recursos que mais degradam a performance são os seguintes, na ordem listados:
- Quantidade de usuários.
- Utilização de espaço alem do disponível na memória física + memória virtual
- Quantidade de dados trafegados pela rede
- Velocidade do Processador no servidor
- Velocidade do Processador no cliente
- Utilização de memória virtual
Na regra geral, devemos adotar que se o cliente tem memória disponível para executar a datastore, devemos utilizar datastore, ao contrário, utilizamos o Cursor. Mas, podemos analisar outros fatores antes de determinar qual objeto utilizar, podendo adotar até uma solução mista, por exemplo, recuperar blocos de registros utilizando datastore.
Nenhum comentário:
Postar um comentário