InsertOnSubmitコールする前に何回コールすればよいSubmitChangesですか? 一度に 1 レコードずつ何万ものレコードを返すことができる Web サービスからデータを追加しています。Web サービスのラッパー クラスはレコードをIEnumberableコレクションとして公開し、精巧なチャンキング メカニズムを隠します。
インサートを提出する前に蓄積すべきインサートの数に関するガイドラインはありますか?
質問する
3083 次
4 に答える
3
まあ、私は問題なく一度に複数のテーブルにまたがる数十万のレコードでそれを行いました。実際、このような場合にすべての InsertOnSubmit() に対して SubmitChanges() を呼び出すと数時間かかりますが、最後に SubmitChanges() を呼び出すだけで、多くのレコードを挿入するのにかかる時間が数分に短縮されます。
上記のケースでは、ヘッダー テーブル、詳細テーブル (ヘッダーにリンク)、およびアトム テーブル (詳細にリンク) を含むテーブルをレポートするための配置がありました。すべてのヘッダー レコードに対して、複数の詳細テーブルがあり、複数のアトム レコードによって再びリンクされていました。場合によっては、膨大な数のレコードを挿入することになり、最後に 1 回の SubmitChanges() 呼び出しですべて問題なく実行され、すべてが非常にうまく機能しました。
于 2010-07-01T01:58:43.200 に答える
3
また、挿入する必要があるデータの種類によっても異なります。別のテーブルにさらにレコードを挿入するために、ID も必要な場合に、多くのレコードを挿入する必要がある場合があります。
データベースに変更を送信すると ID が割り当てられるため、特定の時間に SubmitChanges を呼び出す必要があります。
これが必要ない場合は、一度に 1000 個ほど送信します (挿入する必要があるレコードの総数によって異なります)。
たぶん、あなたに最適な速度テストを行うことができます. ハードウェア、レコード数の目安などにより異なります。
于 2010-07-01T10:07:09.763 に答える
1
一言で言えば、実際には「ガイドライン」はありません。効率のためには、1 万個ではなく、100 個ほど集めたいと思いますか? これにより、DB クエリが大幅に削減され、トランザクションを構築している間、ローカルにキャッシングする RAM を使いすぎてはいけません。
ただし、いくつかの異なる値でテストし、パフォーマンス (メモリと速度) をプロファイルして、ハードウェアに最適なソリューションを見つける必要があります。
于 2010-07-01T00:03:48.800 に答える