数分前、私は上司と話し合いましたが、私が間違っているか、彼が間違っているかをもっと知りたいと思っています。
次の問題が与えられます: 同僚からの素早い変更の後、ストアド プロシージャに問題が発生しました。（ここでの理論については、これ以上必要な情報はないと思います）
更新スクリプトで正しいバージョンを提供することにしました。
手順 X が存在する場合 .... 手順 X を削除 .... 手順 X を作成 ....
修正が実行される DBO については、ロールバック メカニズムを準備する必要があります (すべきです)。上司が私のところに来て、ロールバック スクリプトの準備を依頼してきました。メインスクリプトが失敗した場合、オプションがないためです。間違ったものにロールバックすることはできません。無意味です。
彼は私たちにそれが必要であり、それは無意味ではないと私に言いました..
私が理由を尋ねると、彼は去っていきました。
私は間違っていますか？
あなたの言っていることにはある程度の論理がありますが、その議論が「機能していないコードをバックアップする必要はない」と言っているのと同じなら、私はあなたの上司に同意できます。
それはまだ誰かの高価な時間を費やしたものであり、欠陥は小さなものかもしれません. 更なる更新によって事態がさらに悪化する可能性があると考えられる場合は、壊れていない状態にロールバックする機能を要求するのが妥当です。
これがダウンタイムが望ましくない運用サーバーである場合は、ロールバック手順が必要です。その手順が、アップグレードの前にデータベースをバックアップし、障害時にバックアップから復元するだけであっても。
また、「プロシージャの作成」が機能するかどうかも暗示しています。これは事実ですが、手順が実際に機能するという意味ではありません。存在しないテーブルを参照するストアド プロシージャ (少なくとも SQL Server では) を作成でき、問題なくコンパイルされます。
同僚からの迅速な変更の後、ストアド プロシージャに問題が発生しました。（ここでの理論については、これ以上必要な情報はないと思います）
詳細情報が必要です。
スクリプトを変更するとき、同僚は次の 2 つのことを行いました。
このスクリプトを作成する必要があるかどうかは、次の要因によって異なります。
2つの間違いは正しいことにはなりません。
SP への以前の変更にロールバック オプションがあった場合、このような状況にはなりません。したがって、ロールバックが「悪い」バージョンになることはわかっていますが。それはまだそこにあるはずです。
ここで行う更新は、現在よりもはるかに多くのことを壊す可能性があります.