私たちの Windows フォーム アプリケーションは、ADO.NET と SOAP Web サービスを介して SQL Server のビューからレコードを取得し、データ グリッドに表示します。25,000 行までのケースがいくつかありましたが、これは比較的スムーズに機能しますが、潜在的な顧客は 1 つのリストにその何倍もの行を含める必要があります。
現時点でどれだけうまくスケーリングできるか、またどのように (そしてどこまで) 現実的に改善できるかを把握するために、シミュレーションを実装したいと思います。実際のデータを表示する代わりに、SQL Server に架空のランダム データを送信させます。クライアント側とトランスポート側はほとんど同じです。もちろん、ビュー (または少なくとも基になるテーブル) の動作は異なります。ユーザーは、架空の行数 (たとえば、100,000) を指定します。
とりあえず、クライアントがデータを取得して処理し、表示する準備が整うまでにかかる時間を知りたいだけです。
私が理解しようとしているのはこれです:SQL Serverにそのようなデータを送信させるにはどうすればよいですか?
私は:
- 実際のテーブルを埋めるために事前に実行する必要があるストアド プロシージャを作成しますか?
- ビューを指す関数を作成して、サーバーに「ライブ」データを生成させますか?
- どういうわけか既存のデータを複製および/またはランダム化しますか?
最初のオプションは、現実世界に最も近い結果が得られるように思えます。データは実際には「物理的にそこにある」ため、SELECT
クエリは実際のデータに対するクエリとパフォーマンス的に非常に似ています。ただし、それ以外の場合は無意味な操作でサーバーに負担がかかります。偽のデータも同じデータベースに存在するため、バックアップされます。もちろん、ベンチマークを実行するたびにデータを削除しない限り.
2 番目と 3 番目のオプションは、実際のシミュレーションの実行中にサーバーに負担をかけるため、結果が非現実的に遅くなる可能性があります。
さらに、ループやカーソルを使用しない限り、これらの行を作成する方法がわかりません。実際にエントリがSELECT top <n> random1(), random2(), […] FROM foo
ある場合は使用できますが、それ以外の場合は (明らかに) たまたまある行だけを取得します。Aまたは類似のものは、そのトリックを行うようには見えません。foo
<n>
foo
GROUP BY newid()