Últimos assuntos
A ordem dos argumentos altera o tempo de processamento
Página 1 de 1
A ordem dos argumentos altera o tempo de processamento
A ordem dos argumentos altera o tempo de processamento
Em um FILTRO a Ordem dos Argumentos da pesquisa faz muita diferença, ou, em outras palavras “A Ordem dos Fatores altera o tempo/custo necessário para se obter o produto.
O custo de processamento de uma Consulta (Filtro) é determinado quase que 100 % pelo gasto com o acesso ao(s) disco(s). Em filtros com mais de um Argumento, sempre há mais de uma estratégia na hora de montar a Expressão do Filtro. Principalmente para Filtros complexos, que buscam dados em mais de uma Tabela Relacionada.
Uma estratégia ruim pode gerar grande impacto no processamento. Consequentemente, quando tratamos grandes volumes de dados, vale a pena parar e pensar em uma boa estratégia de pesquisa antes de executar um Filtro.
Segue...
Em um FILTRO a Ordem dos Argumentos da pesquisa faz muita diferença, ou, em outras palavras “A Ordem dos Fatores altera o tempo/custo necessário para se obter o produto.
O custo de processamento de uma Consulta (Filtro) é determinado quase que 100 % pelo gasto com o acesso ao(s) disco(s). Em filtros com mais de um Argumento, sempre há mais de uma estratégia na hora de montar a Expressão do Filtro. Principalmente para Filtros complexos, que buscam dados em mais de uma Tabela Relacionada.
Uma estratégia ruim pode gerar grande impacto no processamento. Consequentemente, quando tratamos grandes volumes de dados, vale a pena parar e pensar em uma boa estratégia de pesquisa antes de executar um Filtro.
Segue...
GERADOR DE ESTIMATIVA: CUSTO X CARDINALIDADE
GERADOR DE ESTIMATIVA: CUSTO X CARDINALIDADE
Tomando emprestados alguns conceitos de Otimização em Banco de Dados Relacionais, podemos simular um “Plano de Execução” da nossa consulta, baseado em uma estimativa do Custo de Processamento pela Cardinalidade dos Argumentos de Pesquisa.
Custo de Processamento: Este custo leva em consideração a porção utilizada do processador, memória, quantidade de acessos ao disco ou qualquer outro recurso do computador ou da rede (obs.: só em último caso trabalhe com arquivos armazenados em rede).
Cardinalidade: A cardinalidade representa o número o número de linhas distintas retornadas por um Argumento de Pesquisa de uma Expressão de Filtro.
Como conceito acessório para se trabalhar bem com a Cardinalidade temos que conhecer a Seletividade do conteúdo dos CAMPOS.
Seletividade: Se um filtro aplicado naquele Campo da Tabela retorna poucas linhas dentro de um universo de milhões, ele é dito seletivo e consequentemente bom para pesquisa.
Ex.: em uma tabela de Clientes, temos as colunas CPNJ e TIPO_PESSOA = “J” ou ‘F”.
Podemos estimar que TIPO_PESSOA tenha Seletividade baixa, pois quando aplicado ele deve retornar uma grande quantidade de linhas. Por outro lado, a coluna CPF pode ser altamente seletiva, pois para um CNPJ deverá existir apenas um registro dentre todos os registros da tabela.
Segue...
Tomando emprestados alguns conceitos de Otimização em Banco de Dados Relacionais, podemos simular um “Plano de Execução” da nossa consulta, baseado em uma estimativa do Custo de Processamento pela Cardinalidade dos Argumentos de Pesquisa.
Custo de Processamento: Este custo leva em consideração a porção utilizada do processador, memória, quantidade de acessos ao disco ou qualquer outro recurso do computador ou da rede (obs.: só em último caso trabalhe com arquivos armazenados em rede).
Cardinalidade: A cardinalidade representa o número o número de linhas distintas retornadas por um Argumento de Pesquisa de uma Expressão de Filtro.
Como conceito acessório para se trabalhar bem com a Cardinalidade temos que conhecer a Seletividade do conteúdo dos CAMPOS.
Seletividade: Se um filtro aplicado naquele Campo da Tabela retorna poucas linhas dentro de um universo de milhões, ele é dito seletivo e consequentemente bom para pesquisa.
Ex.: em uma tabela de Clientes, temos as colunas CPNJ e TIPO_PESSOA = “J” ou ‘F”.
Podemos estimar que TIPO_PESSOA tenha Seletividade baixa, pois quando aplicado ele deve retornar uma grande quantidade de linhas. Por outro lado, a coluna CPF pode ser altamente seletiva, pois para um CNPJ deverá existir apenas um registro dentre todos os registros da tabela.
Segue...
DICAS...
A seguir listo algumas considerações como orientação geral para o planejamento de uma Expressão de Filtro. Frisando que cada caso precisa ser analisado dentro a sua própria especificidade.
1. Os Argumentos (ou condições) mais restritivos devem ser avaliados em primeiro lugar. Dessa forma, um subconjunto menor de dados é selecionado e passa para ser avaliado para o argumento seguinte da Expressão do Filtro, reduzindo os “overheads” da consulta.
2. Dê preferência para as Operações mais Simples (OPERADOR “=”) e depois para as complexas (AND / OR)
3. Dê preferência para o uso de funções como as MATCH() e a BETWEEN() no lugar do Operadores Lógicos AND / OR ex:
MATCH(ANO;2015;2014) e não ANO = 2015 AND ANO = 2014;
BETWEEN(ANO;`20140101´;`20151231` e não ANO >= ;`20140101` AND ANO <=´;`20151231`
4. Com relação aos Campos que você vai utilizar nos Argumentos:
a) Primeiro os campos da TABELA PAI,
b) Depois os das MENORES TABELAs FILHO;
c) Em seguida os Campos de MENOR TAMANHO;
5. Dê preferência para a pesquisa por Código em detrimento das Descrições.
6. Dê preferência para os “campos físicos” (aqueles definidos no Layout com base na posição física na origem de dados) e detrimento de “campos calculados”.
6. Sempre que possível evite aplicar Funções de conversão de campos.
7. Dê preferência para o Padrão não UNICODE (por ser um padrão criado para representar qualquer de escrita, ele utiliza uma quantidade maior de bytes no seu sistema de armazenamento).
1. Os Argumentos (ou condições) mais restritivos devem ser avaliados em primeiro lugar. Dessa forma, um subconjunto menor de dados é selecionado e passa para ser avaliado para o argumento seguinte da Expressão do Filtro, reduzindo os “overheads” da consulta.
2. Dê preferência para as Operações mais Simples (OPERADOR “=”) e depois para as complexas (AND / OR)
3. Dê preferência para o uso de funções como as MATCH() e a BETWEEN() no lugar do Operadores Lógicos AND / OR ex:
MATCH(ANO;2015;2014) e não ANO = 2015 AND ANO = 2014;
BETWEEN(ANO;`20140101´;`20151231` e não ANO >= ;`20140101` AND ANO <=´;`20151231`
4. Com relação aos Campos que você vai utilizar nos Argumentos:
a) Primeiro os campos da TABELA PAI,
b) Depois os das MENORES TABELAs FILHO;
c) Em seguida os Campos de MENOR TAMANHO;
5. Dê preferência para a pesquisa por Código em detrimento das Descrições.
6. Dê preferência para os “campos físicos” (aqueles definidos no Layout com base na posição física na origem de dados) e detrimento de “campos calculados”.
6. Sempre que possível evite aplicar Funções de conversão de campos.
7. Dê preferência para o Padrão não UNICODE (por ser um padrão criado para representar qualquer de escrita, ele utiliza uma quantidade maior de bytes no seu sistema de armazenamento).
Página 1 de 1
Permissão deste fórum:
Você não pode responder aos tópicos neste fórum
|
|
» Exportar Arquivos em quantidades (blocos) fixos de linhas.
» GRUPO DE ESTUDOS AUDIT ANALYTICS
» Cálculo do número da Semana no ano
» A ordem dos argumentos altera o tempo de processamento
» Como pegar dados únicos de um campo?
» Existe algum comando no Analyzer que eu realize as instruções do SQL?
» Lei de Benford: How Forensic Accountants Use Benford's Law To Detect Fraud
» Importação de PDF