linq-to-sql のようなものを使用している場合DataContext
、Linq 自体ではなく、実際に更新を行うのはオブジェクトです。
私が見る限り、あなたには3つのオプションがあります:
1) オブジェクトを使用して、変更されたオブジェクトDataContext
を に追加します。ただし、Terry Aney が指摘したように、このアプローチにはパフォーマンスのオーバーヘッドに関する深刻な問題がいくつかあります。Price_Old
DataContext
2)PRICE_NEW
別のテーブルの場合UpdateBatch
、Terry Aney が紹介した方法と同様の方法を使用できますが(上記のリンクを参照)、残念ながら、既存のデータのリストをそれぞれに新しい値で指定できるバリアントは見つかりませんでした。ユニークな列。しかし、存在する場合、結果の SQL は次のようになります。
UPDATE
PRICE_OLD
SET
PRICE =
(
SELECT
PRICE
FROM
PRICE_NEW
WHERE
PRICE_OLD.DATE=PRICE_NEW.DATE
AND PRICE_OLD.HOUR = PRICE_NEW.HOUR
)
WHERE
EXISTS
(
SELECT
PRICE
FROM
PRICE_NEW
WHERE
PRICE_OLD.DATE=PRICE_NEW.DATE
AND PRICE_OLD.HOUR = PRICE_NEW.HOUR
)
このような作業を開始すると、この SQL をストアド プロシージャにラップしてDataContext
、コードに追加して呼び出すことができます。式ツリーを操作する方法を理解するのが楽しくないわけではありません。残念ながら、これでもやりたいことはできません。ある種のデータ テーブルでデータを操作し、魔法のように更新をデータベースに適用します。それは私をもたらします
3) に対して行った変更を尊重する単一の SQL 文字列を生成する場合、DataTable
Linq などを介して行う場合、UPDATE
ステートメントは大量のCASE
ステートメントを含み、次のようになります。
UPDATE
PRICE_OLD
SET
PRICE = CASE WHEN ID =1 THEN 3 WHEN ID = 2 THEN 3.1...
WHERE
ID IN
(
1, 2, ...
)
文字列を作成する場所で、文字列から読み取った値を動的に渡しますDataTable
(もちろん、すべてパラメーター化で実装されています)。ご覧のとおり、これは見栄えが悪く、関連するパフォーマンス オーバーヘッドが負の影響を及ぼしている可能性があります。これを回避するために、次の 3 段階のアプローチを実装します。
a. my と同じスキーマで一時テーブルを作成しますDataTable
。
b. その一時テーブルSqlBulkCopy
にコピーするために使用します。DataTable
c. 上記の #2 で言及した SQL 文字列を使用してPRICE_NEW
、一時テーブルの名前に置き換えます。これにより、パラメータ化を必要とせずにテーブルが正しく更新されます。
これにはいくつかの文字列操作が含まれる場合がありますが、利点はセットベースの更新です。