はじめに
Web開発では、ページング処理を行ったデータにアクセスするという方式が一般的です。レポートやデータベーステーブルの内容全体をエンドユーザーに表示するのではなく、通常は、ページ間を移動するコントロールを用意して、Webページ1ページ分のレコードのサブセットだけを表示します。ASP.NET 1.xでは、DataGridのおかげでページング処理が非常に簡単になりました。DataGridのAllowPagingプロパティをTrueに設定し、PageIndexChangedイベントハンドラに数行のコードを追加するだけで終わりです。ASP.NET 2.0のGridViewでは、このプロセスがさらに簡単になっています。GridViewのスマートタグで［ページングを有効にする］チェックボックスをオンにするだけです。コーディングは必要ありません。
もちろん、どのようなことにも代償は付きもので、［ページングを有効にする］チェックボックスをオンにする（DataGridの場合は、コードを数行書く）という簡便さを選んだ場合は、パフォーマンス面での妥協が生じます。何もしなければ、DataGridとGridViewは既定のページング処理を行います。これは、1ページ分のデータを表示するたびにすべてのレコードを返す単純なページング処理モデルです。ページング処理対象のデータが少なければ（レコード数が10個から100個程度であれば）、パフォーマンスが悪くてもこの機能を設定する簡便さの方が勝るでしょう。しかし、数千、数万、数十万のレコードをページング処理する必要がある場合は、既定のページング処理モデルは現実的ではありません。
既定のページング処理に代わる手段がカスタムのページング処理です。この場合は、データの適切なサブセットをインテリジェントに取得するコードを書かなければなりません。仕事が少し増えますが、非常に大きいサイズのデータを処理する場合には不可欠です。ASP.NET 1.xでカスタムのページング処理を実装する方法については、拙書『ASP.NET Data Web Controls Kick Start』をご覧ください。本稿では、SQL Server 2005の新機能ROW_NUMBER()を使ってASP.NET 2.0でカスタムのページング処理を実装する方法を説明します（ROW_NUMBER()など、SQL Serverの新しい順序付け機能については、『Returning Ranked Results with Microsoft SQL Server 2005』を参照してください）。
それでは、始めましょう。
既定のページング処理とカスタムのページング処理の違い
ASP.NET 2.0のGridView（およびASP.NET 1.xのDataGrid）には、既定のページング処理とカスタムのページング処理の2つのページング処理モデルがあります。この2つのモデルでは、パフォーマンスを選ぶか、設定/構成/使用の簡便さを選ぶかという判断が強いられます。SqlDataSourceコントロールは既定のページング処理を使用します（カスタムのページング処理を使うことも可能ですが、非常に手間がかかります）。ObjectDataSourceコントロールも通常は既定のページング処理を使いますが、メカニズムが簡単なので、カスタムのページング処理を使うようにしてもそれほど負担は大きくありません。GridViewは単にデータを表示するだけであることを忘れないでください。データベースから実際にデータを取得するのは、GridViewのデータソースコントロールです。
既定のページング処理では、新しいページのデータをGridViewに表示するたびに、GridViewのデータソースからすべてのデータが取得されて返されます。すべてのデータが返されると、GridViewは、ユーザーに表示するページと1ページに表示するレコード数に基づいて、すべてのデータの中からデータの一部を選択して表示します。ここで大切なことは、1ページ分のデータを読み込むたびに、つまり、最初のページアクセスで1ページ目のデータを表示するときでも、ユーザーが別のページを表示するよう要求した後でポストバックしたときでも、必ずデータ結果全体が取得されるということです。
例えば、eCommerceという会社で、この会社が販売している150製品の一覧をページング処理してユーザーに表示するとしましょう。特に、ページあたり10個のレコードを表示したいと思います。さて、ユーザーがWebページにアクセスすると、データソースコントロールによって150個のレコードすべてが返されますが、GridViewには最初の10製品（製品1～10）が表示されます。次に、ユーザーが次のページに移動するとします。これによりポストバックが発生し、GridViewはデータソースコントロールに150個のレコードすべてを再び要求しますが、このときに表示されるのは2セット目の10製品（製品11～20）だけです。
EnableCachingプロパティを設定するだけで、返されるDataSetをキャッシュに格納することができます。DataSetのキャッシングにより、ページング処理対象のデータはメモリにキャッシュされるので、別のページに移動するときにデータベースを要求する必要がなくなります。ただし、最初のページを読み込むときは同じ問題が生じます。つまり、すべてのデータをキャッシュ内のDataSetに読み込まなければなりません。さらに、このアプローチには、古いデータが表示されるという問題もあります（ただし、SQLキャッシュ依存を使った場合はこの点について議論の余地があります）。私のあまり正確とは言えないテストでは、DataSetをキャッシュしても、カスタムのページング処理の方が2倍高速であることが判明しました。しかし、後でパフォーマンス値を検討するときに詳しく説明しますが、このキャッシングアプローチは非キャッシングアプローチよりもはるかに優れています（ただし、カスタムのページング処理アプローチにはかないません）。
SqlDataSourceから返されるDataSetのキャッシングの詳細については、『SqlDataSourceコントロールによるデータのキャッシュ』を参照してください。
カスタムのページング処理では、開発者の仕事がもう少し増えます。GridViewをデータソースコントロールにただバインドして［ページングを有効にする］チェックボックスをオンにするのではなく、特定のページに表示する必要があるレコードのみを選択して取得するように、データソースコントロールを設定しなければなりません。このアプローチのメリットは、1ページ目のデータを表示するときに150個すべてのレコードを取得するのではなく、SQLステートメントを使って1～10番目の製品だけを取得できる点です。ただし、このSQLステートメントは150個のレコードの中から正しいサブセットだけを取り出せるくらい「賢く」なければなりません。
カスタムのページング処理はパフォーマンスが優れているのに対し、既定のページング処理は使いやすさに優れています。そのため、ページング処理対象のデータが比較的少ない場合や、データベースサーバのトラフィックがあまり大きくない場合には、既定のページング処理を使うことをお勧めします。ページング処理対象のレコード数が数百、数千、数万に及ぶ場合は、もちろん、カスタムのページング処理を使用してください。ただし、現時点でまだFAQの数が200個にも満たないASPFAQs.comデータベースのようなデータベースをページング処理する場合は、既定のページング処理で十分です。
（もちろん、レコード数が75個しかないような小さいテーブルで既定のページング処理を使う場合は、この先もずっとそのテーブルの行数が少ないままであることが前提になります。今は小さいけれども後でレコード数が7,500件にも増加するテーブルで既定のページング処理を使うと、お客様の不満を招くことになります！）
