私が対処しなければならなかった最も厄介な問題の1つは、ストアドプロシージャグループに関係しています。ストアドプロシージャを指定するとusp_DoSomethingAwesome、を呼び出すことで別のグループにそのプロシージャを作成できますusp_DoSomethingAwesome;2。
システムによって生成された挿入、更新、および削除のレプリケーションストアドプロシージャの一部で発生したレプリケーションの問題（パブリッシャー：SQL 2000 Ent。、Dist / Sub：2008 R2 Ent。）のトラブルシューティングでこれを発見しました。
この「グループ化」能力を持つ背後にある目的/考え方は何ですか？
回答:
これはメソッドをオーバーロードするようなものです。基本的に、ストアドプロシージャの2つ以上のバージョンを作成できます。それぞれが異なることを行います-異なる数のパラメーターの取得、異なるテーブルの操作、異なる出力の作成など。
これらは番号付きプロシージャと呼ばれ、完全に非推奨です（2005年以降に発表されています）。これらはSQL Server 2012でも引き続きサポートされますが、一部の機能はそれらとうまく機能しません。たとえば、それらは包含データベースの包含違反と見なされ、1より大きい番号の手順は作成されません。
メッセージ12829、レベル16、状態1、プロシージャblat、行1
ストアドプロシージャ 'dbo.blat'は、番号付きストアドプロシージャのグループを指します。包含データベースでは、番号付きストアドプロシージャは使用できません。含まれているデータベースの詳細については、Books Onlineのトピック「含まれているデータベースについて」を参照してください。
ストアドプロシージャをグループ化する機能（廃止予定）は、単一の（かなりばかげた）目的、つまり単一のDROPステートメントを介した一括削除機能のために存在するようです。ストアドプロシージャの作成に関するSQL Server 2000 MSDNドキュメントによると：
グループ化
異なる識別番号が与えられている場合、既存のストアドプロシージャと同じ名前でプロシージャを作成できます。これにより、プロシージャを論理的にグループ化できます。同じ名前のプロシージャをグループ化すると、それらを同時に削除できます。同じアプリケーションで使用されるプロシージャは、多くの場合、このようにグループ化されます。たとえば、my_appアプリケーションで使用されるプロシージャには、my_proc; 1、my_proc; 2などの名前が付けられます。削除MY_PROCは、グループ全体を削除します。プロシージャがグループ化された後、グループ内の個々のプロシージャは削除できません。
同じベース名を使用してもオーバーロードが許可されないため（シグネチャは一意である必要がなく、特定の「番号」への自動実行ルーティングがないため）、この構造を使用することによる追加の利点はありません。実行時に「番号」を使用します。したがって、「愚かな」という決定（そして、おそらくそれはあまりにも素晴らしいことです;-)。