A consulta de paginação é um problema frequentemente encontrado. Vejamos primeiro o motivo da existência da consulta de paginação:
Conveniência do usuário: é impossível para os usuários visualizar todos os dados de uma vez, por isso é melhor navegar página por página.
Melhorar o desempenho: buscar todos os dados do banco de dados de uma vez será mais lento.
Então agora deixe-me tentar refutar as razões acima:
É realmente conveniente? Consideramos a seguinte situação se houver apenas 20 dados.
Se os dados excederem 1.000 itens.
O primeiro tipo obviamente não requer consultas de paginação. O estranho é que o segundo não é necessário, porque nenhum usuário está disposto a virar página por página até o fim. Se os dados que o usuário consulta excederem o intervalo de dados de seu interesse, acho que ele deveria ter permissão para inseri-lo novamente. as condições de consulta, assim como nós. O mesmo que usar o Google.
Mas por ser uma interface de aplicativo amigável, sempre esperamos que o usuário possa entender totalmente os resultados de sua consulta, por isso é necessário dizer ao usuário: "Quantos dados você encontrou? No entanto, atualmente apenas os primeiros 1.000 itens podem ser exibidos. Se você deseja visualizar todos os dados, então o que deve ser feito..."
O desempenho melhorará?
Se a quantidade de dados for pequena, obviamente o desempenho não será significativamente melhorado. Pelo contrário, o desempenho será bastante reduzido. Porque o banco de dados executa consultas e condições de consulta desnecessárias.
Se a quantidade de dados for grande, o desempenho pode não ser significativamente melhorado, porque você sempre terá que executar uma consulta de contagem adicional e, ao combinar SQL, é muito provável que cause uma varredura completa da tabela. Claro, isso depende do princípio de implementação do banco de dados.
Pode-se imaginar que a relação entre o impacto das consultas de paginação no desempenho e a quantidade de dados deve ser uma curva. Quando a quantidade de dados for pequena, o desempenho será reduzido, e quando a quantidade de dados for grande, o desempenho. pode (dependendo dos diferentes bancos de dados) ser melhorado. A chave é encontrar o ponto de inflexão da curva por meio de testes. O desempenho não é obtido com base na experiência e no sentimento, mas através de testes. Além disso, se todos os dados forem retirados de uma vez, isso realmente afetará o desempenho do espaço.
Impacto negativo Para uma aplicação web bem arquitetada, é realmente desconfortável passar pageNo e PageSize entre várias classes. Esses dois dados obviamente pertencem à camada de apresentação. Claro, se você usa RoR, não mencionei isso.
Aumenta significativamente a complexidade da programação, especialmente quando se considera a independência do banco de dados.
Fenômeno estranho: por que um grande banco de dados não fornece consultas de paginação diretamente? O RowNo do Oracle não é usado para paginação, nem o Top do SQLServer.
para concluir
ExtremeTable, DisplayTag e JSF DataTable fornecem métodos de paginação simples, ou seja, paginação na coleção de resultados. É muito conveniente de usar e deixa a lógica clara, o que melhora muito a eficiência do trabalho. Na maioria dos casos, este método pode ser usado diretamente.
Se você descobrir, por meio de testes, que o método acima afeta o desempenho, considere usar consultas de paginação.
Para aplicações com grande número de usuários, consultas de paginação também podem ser consideradas devido a restrições de memória. No entanto, eu pessoalmente recomendo o método de cache: a mesma consulta é colocada em um cache...
Use um design razoável para proteger os desenvolvedores de lidar com a lógica de paginação. Por exemplo, a lógica de paginação e a consulta de contagem são colocadas na classe pai e o desenvolvedor é responsável por combinar as condições de consulta. Vejamos especificamente os padrões de design.
Todos são bem-vindos para discutir! ! !