2

たとえば、「myStoredProcedure」のような名前の sp があります。そして、このストアド プロシージャを「myStoredProcedureNew」という名前で同じサーバーにコピーする必要があります。ベストプラクティスは何ですか?

4

1 に答える 1

2

重要な質問の 1 つは、なぜ手順をコピーしているのかということです。

ロジックを変更してテストしたいことが原因である場合は、実際には同じ手順の新しいバージョンがあります。その場合の最善の方法は、ソース管理からスクリプトを取得し、ロジックを変更してテストすることです。機能する場合は、コードをソース管理にコミットできます。機能しない場合は、以前のバージョンのスクリプトに戻すだけです。

最初のストアド プロシージャを開始点またはテンプレートとして使用して 2 番目のストアド プロシージャを作成する場合、実際には 2 つの別個のプロシージャが必要になります。ここでは、ソース管理から最初のプロシージャを取得し、必要に応じて編集してプロシージャ名とロジックを変更し、別のスクリプト ファイルに保存して、2 番目のスクリプトをソース管理に追加する必要があります。したがって、ソース管理には 2 つのスクリプトがあり、各プロシージャに 1 つずつあります。

これで質問の答えが得られない場合は、手順をコピーする必要がある理由について、さらに詳しい情報を提供してください。

EDIT: 100のプロシージャに対してこれを行いたいと説明し、データベースで古いプロシージャと新しいプロシージャの両方を使用できるようにしたいと説明しました(後方互換性のためだと思います)。同じものに 2 つの異なる名前を付ける必要があるように思えますが、その場合は類義語が役立ちます。

古いプロシージャを参照する新しい名前を使用してシノニムをすばやく作成できるため、コードで新しい名前の使用を開始できます。次に、古いプロシージャを物理的に削除する準備ができたら (もし?)、シノニムを削除してプロシージャの名前を変更できます。これが適切な代替手段であるかどうかは、古いプロシージャ名から新しいプロシージャ名への移行をどのように管理するか、およびソース管理で DDL をどのように管理するかによって異なります。

シノニムが役に立たない場合は、説明した 2 番目のシナリオの手順に従うことができます。小さなスクリプトで 100 個のファイルを簡単にコピーして編集できるはずです。もちろん、ソース管理を使用している限り、間違いを簡単に元に戻すことができます。

于 2012-04-04T09:43:57.723 に答える