0

私はこれに夢中になるつもりです。私はlinqtosqlを初めて使用し、linqの変更追跡の概念をまだ完全には理解していませんでした。単一のDataContextで大量のdbを実行する必要がある状況があります。私は次のような奇妙なものがたくさんあることに気づいています：

//Control flows to this statement, but I dont see
//corresponding sql generated in the log.
//However if I instead change it to db.ExecuteCommand("delete from mytable")
//that shows up fine in the log

db.mytable.deleteAllOnSubmit(db.mytable);

これは話の一部にすぎません。しかし、正しいSQLが生成されない場合があるかどうか知りたいですか？1つの可能性として、テーブルからすべての行を削除しようとしていますが、後で同じ正確な行を再度挿入しようとすると、linqは、不要な作業を回避するために、この無視された削除-再挿入を何らかの方法で検出しますか？

4

2 に答える 2

1

deleteAllOnSubmitなどの操作はSQLに変換されず、その場で実行されない ことに注意する必要があります。

ITable.DeleteAllOnSubmitメソッド： コレクションのすべてのエンティティを保留中の削除状態にします。

参照： http： //msdn.microsoft.com/en-us/library/system.data.linq.itable.deleteallonsubmit.aspx

次の操作を行うまで、削除は行われません。

  db.SubmitChanges();

アップデート1：

テーブルが空の場合、削除ステートメントは発生しません。さらに、SubmitChangesその仕様により、特定のシナリオで賢くしようとすることが許可されていますが、トリガーが実行されると思った場合は失望します。削除/挿入トリガーがある場合は、LINQの「削除」の後にSubmitChangesを使用することを検討してください。

DataContext.SubmitChangesメソッド： 挿入、更新、または削除される変更されたオブジェクトのセットを計算し、適切なコマンドを実行してデータベースへの変更を実装します。

http://msdn.microsoft.com/en-us/library/system.data.linq.datacontext.submitchanges.aspx

注：この更新は、OPが呼び出されたときにテーブルが空であることを確認し、確認した後に行われましたSubmitChanges()。後の時点で、OPは、データがテーブルから削除されて同一のデータに置き換えられた場合にもこれが発生することを確認しました。

アップデート2：

@ブライアンあなたがこのようなもので進歩していると聞いてうれしいです:-)

一般的なアドバイス：

  1. 何をしているのかわからない限り、ExecuteCommandとL2Sを混在させないでください。ExecuteCommandは、L2Sの足元にあるデータベースの状態を変更し、（当然のことですが）頭痛の種になる可能性があります。このような頭痛の種を恐れていない場合は、ExecuteCommandL2Sがテーブルにアクセスする前に、行を削除してみてください（より高速ですが、正しく実行する必要があります）。このような頭痛の種を恐れていて、SQLサーバーで「削除時」イベントを発生させたい場合SubmitChangesは、質問のコードでL2Sの「削除」の後に実行してください。
  2. を使用して、データベースとのきめ細かいL2Sインタラクションに依存することもできますがSubmitChanges、長期的には、まったく新しい方法でデータベースとインタラクションするためのツールが提供されていることを理解する方がはるかに優れています。L2Sは賢くしようとしますが、それは悪くありません。あなたの利点にそれを使用してください！この特定のケースでは、何もしなくても、不要な削除/挿入操作を節約でき、事実上、コードを最適化できます。その賢くしようとするのは間違っていますか？はい、操作を個別に考え、いいえ、実行しようとしているのはコードのアクションの正味の効果でDBを更新することだけだと思う​​場合はありません。
于 2012-12-05T17:02:53.470 に答える
1

したがって、ExecuteCommandを使用してlinqを通常のSQLステートメントと混合することはお勧めできませんか？

変更追跡メカニズムに依存する場合は、絶対にしないでください。データコンテキストは「古くなった」状態になります。

更新 「純粋な」L2Sに固執する場合、すべての挿入/更新/削除は適切なSQLに変換されます。また、SubmitChangesを1つ使用する限り、1つのトランザクションでも実行されます。結局、それほど悪くはありません。L2Sは、データベース全体をスキャンせずに、たとえばストアドプロシージャによって引き起こされた変更を追跡することは不可能であるため、ExecuteCommandと混合することはできません...必要なものではありません。

基本的なルール：「作業単位」ごとに1つのDCを作成し、それに対して1つのSubmitChangesのみを実行します。これで、L2を使用しても問題ありません

于 2012-12-05T18:44:37.547 に答える