ページング クエリは頻繁に発生する問題です。まず、ページング クエリが存在する理由を見てみましょう。
ユーザーの利便性: ユーザーはすべてのデータを一度に表示することは不可能なので、ページごとに参照することをお勧めします。
パフォーマンスの向上: データベースからすべてのデータを一度に取得すると時間がかかります。
それでは、上記の理由に反論してみます。
本当に便利ですか?データが 20 個しかない場合、次のような状況を考えます。
データが1000件を超える場合。
最初のタイプは明らかにページング クエリを必要としません。奇妙なことに、2 番目の項目は必要ありません。ユーザーがクエリするデータが関心のあるデータ範囲を超えている場合は、再入力を許可する必要があると思います。クエリ条件は、Google を使用するのと同じです。
しかし、フレンドリーなアプリケーション インターフェイスとして、ユーザーがクエリ結果を完全に理解できることを常に望んでいます。そのため、ユーザーに次のように伝える必要があります。「どれだけのデータが見つかりましたか? ただし、現在表示できるのは最初の 1,000 項目のみです。すべてのデータを表示したい場合は、どうすればよいですか...」
パフォーマンスは向上しますか?
データ量が少ない場合、明らかにパフォーマンスは大幅に向上しません。データベースが不必要なクエリとクエリ条件を実行するためです。
データの量が多い場合、追加のカウント クエリを常に実行する必要があり、SQL を組み合わせるとテーブル全体のスキャンが発生する可能性が非常に高いため、パフォーマンスが大幅に改善されない可能性があります。もちろん、これはデータベースの実装原理に依存します。
ページング クエリのパフォーマンスへの影響とデータ量の関係は、データ量が少ないとパフォーマンスが低下し、データ量が多いとパフォーマンスが低下するという曲線になることが想像できます。 (データベースによっては) 改善される可能性があります。重要なのは、テストを通じて曲線の変曲点を見つけることです。性能は経験や感覚で得られるものではなく、実際にすべてのデータを取り出すと、確かに空間性能に影響を与えます。
悪影響 適切に設計された Web アプリケーションの場合、さまざまなクラス間で pageNo と PageSize を渡すのは、明らかにプレゼンテーション層に属します。もちろん、RoR を使用している場合は、それについては触れていません。
特にデータベースの独立性を考慮した場合、プログラミングの複雑さが大幅に増加します。
奇妙な現象: なぜ大規模なデータベースはページング クエリを直接提供しないのでしょうか? Oracle の RowNo はページングには使用されず、SQLServer の Top も使用されません。
結論は
ExtremeTable、DisplayTag、および JSF DataTable はすべて、単純なページング メソッド、つまり結果コレクション内のページングを提供します。非常に使いやすく、ロジックが明確になるため、作業効率が大幅に向上します。ほとんどの場合、このメソッドは直接使用できます。
テストを通じて上記の方法がパフォーマンスに影響を与えることがわかった場合は、ページング クエリの使用を検討してください。
多数のユーザーがいるアプリケーションの場合、メモリの制約によりページング クエリも考慮されることがあります。ただし、個人的にはキャッシュ方法をお勧めします。同じクエリをキャッシュに配置します。
合理的な設計を使用して、開発者がページング ロジックを扱わないようにしてください。たとえば、ページング ロジックとカウント クエリは親クラスに配置され、開発者はクエリ条件を組み合わせる必要があります。具体的にデザインパターンを見てみましょう。
誰でも議論することを歓迎します！ ！ ！