[共有] mysqlベースのページングプログラムの完全なソリューション（通常のページング/セグメント化されたページング/オリジナルのページング/weiboのsince_idタイプのページングを含む）

[共有] mysqlベースのページングプログラムの完全なソリューション（Weiboの通常のページング/セグメント化されたページング/オリジナルのページング/since_idタイプのページングを含む）
この記事のブログアドレス: http://blog.csdn.net/lgg201/article /details/7757494

この記事に含まれるソース コードは、http://download.csdn.net/user/lgg201 からダウンロードするか、対応するブログ投稿で参照できます。

SQL 解析方法は多数あります。不足している点があれば修正してください。

0. ダウンロード:
このプログラムは自由に改変して配布することができ、http://download からダウンロードできます。 .csdn.net/user/lgg201
1. ページングの必要性
現在のインターネットおよび企業情報システムの主な役割は、大量のデータから適切なデータを見つけることです。
準拠 通常、条件のデータは数万個あり、ユーザーが一度に受け取る情報の量は非常に少ないです。ユーザーの条件を満たす情報が一度にユーザーに表示されます。ほとんどのシナリオでは、ほとんどのデータは冗長になります。
情報の取得が完了した後、データは送信 (ストレージ メディアからアプリケーションへ) などを経る必要があります。したがって、この冗長性を減らすために、セグメント化された情報検索メカニズムが必要です。
ページングの開発
基本的なページング プログラムは、データを次のように分割します。 ceil (total_record / page_size) ページごとのレコード数 (page_size) に応じて、最初のデータの段落がユーザーに表示されます。その後の対話プロセス中に、ユーザーは特定のページに移動することを選択できます。
その後、主に Weibo アプリケーションの出現後、情報の急速な変化により、その特徴は、このように、基本的なページング プログラムでは対応できなくなりました。ニーズ: a) 次のページを取得するときに、データ セットが大幅に変更されている可能性があり、ページをめくるたびにデータの重複やジャンプが発生する可能性があります。 b) このようなアプリケーションでは、複数のデータを 1 つの画面上に表示する多くのユーザー インターフェイスが使用されます。これにより、データの重複/ジャンプがユーザー エクスペリエンスに与える影響がさらに悪化します。そのため、プログラマーは、同じユーザー インターフェイスで、次のデータ取得ポイントを記録するために、
を使用するようになりました。ユーザーの読書行動を通じてデータの次/前の段落を自動的に取得することは、「次のページ」ボタンをクリックするユーザー エクスペリエンスよりも確かに優れていますが、欠点もあります。 a) ユーザーが 100 ページに到達したとき、興味のあるページ 5 の情報に戻るのは簡単ではありません。実際、これは 1 つのページにあまりにも多くの画面を含むユーザー インターフェイスを許可することはできません。ユーザー エクスペリエンスが低下します。 ; b) データの観点から見ると、一度に 1 つの画面しか表示されていない場合、複数の読み取り間の間隔はデータに何らかの変化を引き起こすのに十分であるため、これらの問題を見つけるのは困難です。ユーザーエクスペリエンスに影響を与えます)) ただし、1 ページに 100 画面のデータが表示されると、この変化はさらに大きくなります。 c) プログラムの観点から見ると、同じユーザー インターフェイス上に大量のデータが存在すると、ユーザー インターフェイスのプログラム ロジックが影響を受けることは避けられません。上記の考慮事項に基づいて、現在のアプリケーションでは、ページングの見直し、1 ページに表示される画面の数の制限、および追加が開始されています。さらに、データ ロジックの正確性を確保しながら (エラーを減らして) 最適なユーザー エクスペリエンスを実現するために、since_id のメソッドも組み合わせています。
3. ページネーションの議論
4 人の同僚 xp/jp/zq/lw が議論に協力してくれました。多くの議論に基づいて、ページング プログラムの性質を分析しました。主な結論は次のとおりです:
1) ページングの目的はセグメント内のデータを読み取ることです。 🎜> 2) データベースのストレージ順序に依存する場合でも、ページングできるデータは順序どおりである必要があります (これは別の方法で理解しやすくなります。データ セットが変更されない場合、同じ入力が複数回実行されます。 、出力順序は変更されません)
3) すべてのセグメント化されたデータの読み取り データセットの一貫性を完全に保証するには、データセットシーケンスの一貫性、つまりスナップショットを保証する必要があります
4) 従来のページングとセグメント化ページング (各ページは複数のセグメントに分割されます) は、MySQL の SQL 構文にマッピングされたデータ セットに対して最終的に 1 回実行され、入力に基づいて制限句を取得することが適用されるシナリオです。データセットが低い
5) Because_id タイプのページング、その本質は既存のデータが変更されていないと想定することであり、データセットは特定のポイント (データを絶対的に見つけることができる関連フィールド) の ID になります。データセット) がユーザー側に提供され、対応する位置のデータが読み取られるたびに、データセット内の履歴データの変更頻度が低いという使用シナリオがシミュレートされます。データは頻繁に追加されます
6) 各セッションの開始時にデータセットのスナップショット データを生成できるスナップショット システムがあれば、すべての問題は解決されます
7) スナップショット システムがない場合、 nce_id メソッドを使用してデータ範囲を制限し、スナップショット システムをシミュレートすると、ほとんどの問題を解決できます。
8) スナップショットをシミュレートするためにsince_id メソッドを使用するには、データ セットの並べ替えルールに、それぞれを一意に識別できるフィールドが必要です。そのデータ (おそらく複合)
4. 実装のアイデア
1) SQL 変換機能を提供します
2) セグメント化されたページング (page、page_ping、ping、ping_size)、従来のページング (page、page_size) をサポートします。オリジナルページング (offset-count)、since_id ページング (prev_id, next_id)
3) 分割ページング、従来型ページング、オリジナルページングを最下位層でオリジナルページング処理に変換
5. 実装定義
ping_to_offset
入力:
page #要求ページ番号、範囲: [1, total_page]、範囲を超えた場合は境界線で計算され、つまり0は1に修正され、total_page + 1は次のように修正されますtotal_page
ping #リクエストセグメント番号、範囲: [1, page_ping]、範囲を超える場合は境界として計算され、つまり0は1に修正され、page_ping + 1はpage_ping
に修正されます page_ping #番号ページあたりのセグメント数、範囲: [1, 無限]
count #取得するレコードの数、現在のアプリケーション シナリオの意味は次のとおりです: セグメントあたりのレコードの数、範囲: [1, 無限]
total_record #レコードの総数、範囲: [1, 無限]
出力:
offset #Offset
count #項目数の読み取り
offset_to_ping
入力:
offset #Offset ( count に従って整列する必要があります。つまり、count で割ることができます)、範囲: [0, 無限]
page_ping #1 ページあたりのセグメント数、範囲: [1, 無限]
count #Number of読み取り、範囲: [1, 無限]
出力:
page #リクエスト ページ番号
ping #リクエスト セグメント番号
page_ping #ページごとのセグメント数
count #送信するレコードの数現在のアプリケーション シナリオの意味は次のとおりです: セグメントあたりのレコード数
page_to_offset
入力:
page #リクエスト ページ番号、範囲: [1 , total_page]、範囲を超える場合は、境界、つまり0を1に修正、total_page + 1をtotal_page
total_record #総レコード数、範囲: [1, 無限]
count #現時点で取得するレコード数 意味アプリケーション シナリオの次のとおりです: ページあたりのアイテム数、範囲: [1, 無限]
出力:
offset #offset
count #number of items read
offset_to_page
input:
offset #Offset (count に従って整列する必要があります。つまり、count で割り切れる必要があります)、範囲: [0, 無限]
count #読み取る項目の数、範囲: [1, 無限]
出力:
page #リクエストページ番号
count #取得するレコードの数、現在のアプリケーションシナリオの意味は次のとおりです: ページあたりのレコード数
sql_parser #mysql文法に準拠したSQL文を解析します各コンポーネントを取得するための仕様
入力:
sql #解析対象の SQL ステートメント
出力:
sql_components #SQL 解析フィールド
sql_restore #SQL ステートメントコンポーネントセットを SQL ステートメントに変換
入力:
sql_components #復元対象の SQL ステートメント コンポーネント セット
出力:
sql #復元された SQL ステートメント
sql_to_count #mysql 文法仕様に準拠した SELECT ステートメントを変換してカウントを取得
入力:
sql_components #クエリに変換されるカウント対象 SQL 文コンポーネントセット
エイリアス #カウントフィールドのエイリアス
出力:
sql_components #変換されたクエリカウント SQL 文コンポーネントセット
sql_add_offset
入力:
sql_components #オフセット SQL ステートメント コンポーネント セットを追加するには、LIMIT コンポーネントは許可されません
offset #Offset (カウントに従って整列する必要があります。つまり、カウントで除算できます)、範囲: [0,無限]
count #取得するレコード数 数値、範囲: [1, 無限]
出力:
sql_components #LIMIT コンポーネントを追加した SQL 文コンポーネントセット
sql_add_since #since_id 式の範囲を増やす
入力: