Olha, vou te atazanar neste assunto
Essa cultura que vem de aplicações Desktop, lá dos primordios dos DBFs onde se
usavam TTables, cultura muito usada no Clipper também.
Entendo que é muito bom você trabalhar com registros em Cache, mas hoje em dia
com o numero de informações que trabalhamos não é viável.
Você não só prejudica o usuário da maquina que quer todos esses registros, como
toda a rede.
Imagino que você deve estar usando Query.Filter, é rápido quando o grid já está
carregado, mas com o tempo sua aplicação vai começar a travar legal.
Eu já tive este problema com usuários que queriam trabalhar com esse monte de
registros abertos, mas resolvi encaram de frente e mudar essa política.
Hoje meus Grids, trazem os 50 ultimos registros, e a tela de pesquisa dá a
opção pro cara trazer os registros conforme precisa, mas nesta pesquisa ele
pode trazer 1 ou todos os registros... mas aí ele já sabe que se puxar todos os
sistema vai ficar mais lento, ou seja transferi essa responsabilidade pra ele.
De inicio como trago somente os 50 ultimos em todas as maquinas, o servidor não
sobrecarrega nem a rede.
Com o tempo o usuário acaba aprendendo a trabalhar com menos registros e nem
sente falta dos famigerados (todos registros).
Ou seja, a opção está lá, mas ele usa quando quer.
Sinceramente, ainda não consegui encontrar uma boa explicação (ou argumento)
para se trabalhar com tantos registros assim.
A questão de trazer registros conforme um filtro?
Um select resolve isso tranquilamente e você trabalha com dados em tempo
real, não corre o risco de informações obsoletas.
Outra coisa que estou estudando é trabalhar como o facebook quando carrega os
posts, conforme o cara vai chegando proximo dos ultimos registros vou trazendo
mais.
Mas devemos lembrar que o limite não está somente no servidor e rede, mas na
maquina local, pois quando você traz essas informações e não cabe na memoria
ele passa a fazer uso da memoria virtual (no disco) ai não tem jeito, fica
lento mesmo.
Marcelo Silva
From: Junior Miranda
Sent: Friday, March 13, 2015 1:47 PM
To: Comunidade PostgreSQL Brasileira
Subject: Re: [pgbr-geral] Consulta lenta
Tentei fazer isso, é uma mudança de cultura e não foi bem recebida... outros
bancos, como firebird, essa lentidão não é tão acentuada... Alguma sugestão
dentro deste cenário??
Júnior Miranda
Analista de Sistemas
Especializando em Sistemas Computacionais
E-mail: [email protected]
Tel.: (75) 9191-1678/ 34143042/ 34143149/ 34143020
Em 13 de março de 2015 13:43, Vinicius Santos <[email protected]>
escreveu:
Porque não força o usuário a fazer o filtro antes? Abra a tabela depois que
tiver o filtro.
Em 13 de março de 2015 13:34, Junior Miranda <[email protected]>
escreveu:
O usuário visualiza todos num grid e a partir dai realiza os filtros que
desejar.
Júnior Miranda
Analista de Sistemas
Especializando em Sistemas Computacionais
E-mail: [email protected]
Tel.: (75) 9191-1678/ 34143042/ 34143149/ 34143020
Em 13 de março de 2015 13:32, Junior Miranda <[email protected]>
escreveu:
Tenho uma consulta de produtos que possue, no momento, 20 mil registros.
Infelizmente para esta consulta eu precisaria retornar todos para que a partir
dai o usuário pudesse realizar os seus filtros. Com essa quantidade de
registros apresenta uma lentidão na abertura da pesquisa. Não fetch X em X por
que nem sem ele consegui retornar os registros.
Júnior Miranda
Analista de Sistemas
Especializando em Sistemas Computacionais
E-mail: [email protected]
Tel.: (75) 9191-1678/ 34143042/ 34143149/ 34143020
Em 13 de março de 2015 13:27, Matheus de Oliveira
<[email protected]> escreveu:
2015-03-13 13:26 GMT-03:00 Junior Miranda <[email protected]>:
A questão é que inicialmente precisarei retornar todos os registro, e
como a tendência é que eles aumentem um pouco, precisaria fazer FETCH de X em X
para diminuir o gargalo na abertura. A tendência é que com o aumento essa
lentidão aumente...
Poucas informações para que possamos ajudar. Você diz pra fazer de X em
X, mas você não fez isso. Pode compartilhar conosco o uso de tantos registros
assim?
Atenciosamente,
--
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
--------------------------------------------------------------------------------
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
