UPSERT-MERGEまたは@@ rowcountに代わるより良い代替手段はありますか?[閉まっている]


14

UPSERTの概念に似たT-SQLコマンドに出会ったことがありますか?オプション(1)または(2)を使用してINSERT | UPDATE操作を実行すると、過度に複雑でエラーが発生しやすくなります。

目的

目的のレコード(この場合、employee_id 1)が最新であり、本質的に同じクエリを2回記述する必要がないことを確認します。

環境

  • テーブル名:従業員
  • 従業員ID:主キーがあり、IDプロパティがtrueに設定されています

オプション

  1. SQL UPDATEを実行... @@ rowcount = 0および@@ error = 0をチェック...必要に応じてSQL INSERTを実行

    • con:同じクエリを、挿入として1回、更新として1回、事実上2回記述する必要があります
    • con:より多くのコード=より多くの時間入力
    • con:より多くのコード=より多くのエラーの余地

/programming/1106717/how-to-implement-a-conditional-upsert-stored-procedure「@@ rowcountを使用して更新」

  1. SQL MERGEを実行します
    • con:同じクエリを、挿入として1回、更新として1回、事実上2回記述する必要があります
    • con:より多くのコード=より多くの時間入力
    • con:より多くのコード=より多くのエラーの余地

http://technet.microsoft.com/en-us/library/bb510625.aspx「T-SQLマージ」

  1. SQL UPSERTを実行します(機能は存在しません)
    • pro:データとテーブルの関係を一度定義します(SQL ServerがINSERTかUPDATEかどうかを心配させます)
    • pro:コードの削減=実装の高速化
    • pro:少ないコード=低い確率

UPSERTの例

UPSERT employeee(employee_id、employee_number、job_title、first_name、middle_name、surname、modified_at)VALUES(1、'00 -124AB37 '、' Manager '、' John '、' T '、' Smith '、GetDate());

  • employee_id 1が存在しない場合:MS SQLはINSERTステートメントを実行します
  • employee_id 1が存在する場合:MS SQLが実行され、UPDATEステートメント

4
これはMicrosoftの機能要求のようであり、ここで解決できる人はいません。Microsoftが考案したソリューションはMERGEです。それがあなたにとって十分な柔軟性/パワフルでない場合、まだ存在しない別のソリューションが必要です。
アーロンバートランド

3
私の意見でMERGEは、簡単で柔軟性があり、SQL Standardの一部でもあります。MERGEその他のUPSERT実装の実際の問題は、潜在的なロックエスカレーション、または構文とは関係のないデッドロックです。
a1ex07

質問がある場合は、お気軽にお尋ねください。書かれているように、これは基本的MERGEにSQL Serverでの実装に関する論争です。
JNK

良い質問-サーバーが挿入または更新を必要とするかどうかを心配するUPSERTステートメントが本質的にありますか。MERGEは、「UPSERT」の実装に論理的に期待するものを満たしていません。MSがこの方法を実装することを選択したことを考えると、私の質問は次のようになります。欠点(または実装不可能)は、あなた(および私)が望む構文を実装しようとしていましたか?
youcantryreachingme

回答:


14

これに対する簡単な答えはノーだと思います。MERGEより複雑なUPSERTロジックに対するマイクロソフトの答えでした。そして、あなたは最悪のアプローチさえリストしませんでした:

IF (SELECT COUNT ... ) > 0
    UPDATE
ELSE
    INSERT

それをちょっとタイピングして口に放り込んだだけですが、実際に私がよく見かけるものです。

いずれにせよ、MERGEあなたにとって十分な柔軟性や能力がない場合、http://connect.microsoft.com/sql/で機能リクエストをMicrosoftに送信し、ビジネスケースを徹底的に説明することをお勧めします。提案された構文の真の利点に固執する限りMERGE、あなたは私の票を持っています。「エラーが発生しやすい」部分に固執しすぎると、私はあまり賛同しません。なぜですか?声明を太らせることができるからです。

とはいえ、ここで誰かがあなたのために具体的にできることは何もないと思います。潜在的な問題を調査する必要がありますMERGE

http://www.mssqltips.com/sqlservertip/3074/use-caution-with-sql-servers-merge-statement/


2
ありがとうアーロン。MSDNのT-SQLドキュメントを調べましたが、探しているものが見つかりませんでした。私は何かを見逃した場合に私はそこにそれを投げると思いました。MERGEステートメントは特定の状況では意味をなしますが、単純な保存操作のための「釘を打つスレッジハンマー」ソリューションであると感じざるを得ません。おそらくプログラマーの帽子を脱ぎ、DBA Fedoraを身に着けるべきでしょう。ご意見をお寄せいただきありがとうございます。
Pressacco
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.