ストアドプロシージャパラメータの数が多すぎますか？
SQL Server 2008でストアドプロシージャの作成を開始したばかりで、30以上のパラメーターがあります。 10個を超えるパラメータを使用して記述したことはないので、考えさせられました...どの時点でパラメータが多すぎるのですか？
コンテキストについて...この手順は基本的に[〜＃〜] insert [〜＃〜]単一の行を単一のテーブルに挿入します。非常によく似たものもあります。多少小さいですが;同じテーブルで[〜＃〜] update [〜＃〜]を実行するバージョン。ほとんどの列は比較的小さく、intと文字列（varchar(200)）が混在しています。
問題は何ですか。良いまたは悪い;多数のパラメータを持つプロシージャを作成することと、他のパターンの検討を開始する必要があるしきい値は何ですか？
問題？私は何も主張しません。
- 制限は2100パラメータです 。 IIRCはSQL2000以降2100ですが、 ドキュメントエラー は1024であると示唆されています。
- テーブルに（たとえば、Sharepoint-esque sparse column 配置のため）列が1000個あり、ストアドプロシージャを介してアクセスを強制している場合、挿入プロシージャには1000個のパラメーターがある場合があります。何も問題ありません。
- 幅の広いテーブル（30は特に幅が広い）ではない場合は、一時停止してスキーマを確認してください。正規化された人生から始まったテーブルを見つけることは珍しいことではありませんが、怠惰や無謀さによって認識を超えて拡大しています。
- 一連のパラメーターをCSVリストまたはXMLとして渡すことを少しでも考慮しないでください。クエリオプティマイザーをブラインドし、時間や労力をほとんどまたはまったく節約しません。
- クライアントコードを手動でクランクして、多数のパラメーターを持つプロシージャを呼び出さないでください。 T4テンプレート または CodeSmith のようなコード生成ツールが役立ちます。
Joe Celkoは長いパラメーターリストの擁護者であり、詳細については thistwo-part の記事に次のように書いています。
最も簡単な答えは、長いパラメーターリストを使用して、プロシージャ本体内のリストと派生テーブルを作成することです。 SQLサーバーは最大2100個のパラメーターを処理できますが、これは実用的な目的には十分すぎる数です。 SQL Serverは、この点で実際には弱体です。 DB2; 32Kパラメータを渡すことができます。 Oracleは64Kパラメータを持つことができます。
...長いパラメーターリストは、古いパラメーターで構成されています。つまり、入力だけでなく出力にも使用できます。また、オプティマイザが使用する1つのステートメントにも含まれています。
これらのテクニックは常に最良の解決策になると思いますか？もちろん違います。 SQLにはそのようなものはありません。しかし、適切な問題が発生した場合は、一見の価値があります。