レコードが存在する場合は更新し、存在しない場合はレコードを挿入する Upsert ストアド プロシージャを使用するのが好きです。それらがなければ、最初にレコードが存在するかどうかを調べてから、結果に基づいて呼び出す 2 つの別個のストアド プロシージャを用意する必要があります。
UpdateOrDeleteRow というストアド プロシージャを作成していた今日まで、この問題について深く考えたことはありませんでした。名前に「Or」が含まれていることに気付いた途端、私の SRP スパイダーの感覚が働き始め、アップサートは基本的に同じものであることに気付きました。
これはSRPに違反していますか? もしそうなら、それは受け入れられますか？そうでない場合は、どうすればよいですか？
SRP は OOP の原則であり、T-SQL は OOP 言語ではないことは認識していますが、原則の基礎はここでも適用されるべきだと思われます。
SRP- DRY以外に、私がさらに気に入っている別の原則があります。したがって、このシーケンスを 1 か所で呼び出すと、単一の責任について考えることができます。しかし、同じ一連のアクションを何度も繰り返すと、DRY によって重複を削除する必要があります。
ORところで、プロシージャ/メソッド名で避けることができると思います。UpdateOrInsert動作はとても良い名前Saveです。SRPを壊すことはないと思います。
個人的には、この原則が SQL Server に完全に当てはまるとは思いません。ストアド プロシージャは、常に 1 つのアクションだけを実行するとは限りません (また、ストアド プロシージャがクラスと同等であるという概念には欠陥があると思います)。ストアド プロシージャ内のすべてのステートメントを独自のストアド プロシージャに分割するのは意味がないと思います。あなたはこれで絶対にばかげてしまうことができます.
もちろん、他の方法でばかげている可能性があるため、バランスがあります。組み合わせに基づいて 540 の異なることを実行できるように、パラメータを指定する 18 の異なる方法を持つストアド プロシージャは必要ありません。
UPSERT の場合、単一のストアド プロシージャで十分であることをお勧めします。単一の目的を果たすことについて気分を良くしたい場合は、更新/挿入を単一のMERGE. :-) そうは言っても、真剣に、には非常に注意してMERGEください。
コードビハインドで冗長なコードが作成されるため、この場合にプリンシパルを適用する必要があることに同意しません。
最初に UPSERT の動作を調べてみましょう。データが存在するかどうかを確認し、それに基づいて INSERT または UPDATE を実行します。
これを行うコード ビハインドでは、アプリケーションの構造によっては、データベースに対して 2 つの呼び出しを行う必要があります。これは、2 つの接続を開いたり閉じたりすることを意味する場合もあります。
したがって、コードビハインドには 3 つのメソッド (各 proc を実行するメソッド) があり、次にこれらのメソッドのそれぞれを呼び出すメソッドがあり、挿入または更新が必要かどうかを決定するロジックを実行します。
また、データベースには、各アクションを実行するための 3 つの個別のストアド プロシージャがあります。
アップサートに渡すのと同じパラメーターを挿入/更新手順に渡すため、これは構造化されていないコードのように思えます。
UPSERT を使用すると、ストアド プロシージャが 1 つになり、コードビハインドから呼び出されるメソッドが 1 つある接続が 1 つだけ必要になります。これにより、はるかに優れた、よりクリーンなコードが作成されると思います。
Update または Delete 操作を個別に実行する proc が既にある場合は、できれば監査目的でログを記録することで、upsert proc でそれらを個別に呼び出すことができます。そうすれば、複数の場所から呼び出されたとしても、それらの proc だけが作業を行い、物事を管理しやすくすることができます。
単一責任の原則では、オブジェクトを変更する理由は 1 つだけにする必要があります。Upsert ストアド プロシージャを変更する唯一の理由は、テーブル構造が変更された場合です。したがって、upsert ストアド プロシージャを作成しても大丈夫だと思います。