ストアドプロシージャのパラメーターが多すぎますか？

SQL Server 2008でストアドプロシージャの記述を始めたばかりで、30以上のパラメーターがあります。10個以上のパラメーターを持つものを書いたことはありません。

コンテキストのために...この手順は、本質的になりますINSERT単一のテーブルに単一の行を。非常によく似たものもあります。やや小さいが; 同じテーブルでUPDATEを実行するバージョン。ほとんどの列は比較的小さく、intと文字列が混在しています（varchar(200)）。

問題は何ですか。良いか悪いか; 多数のパラメーターを含む手順を作成すること、および他のパターンの検討を開始するしきい値はどれくらいですか？

問題？私は何も主張しません。

• 制限は2100パラメーターです。IIRC SQL2000以降2100でしたが、ドキュメントエラーにより1024であることが示唆されました。
• テーブルに1000個の列があり（たとえば、Sharepoint風の疎な列配置のため）、ストアドプロシージャを介してアクセスを強制している場合、挿入プロシージャには1000個のパラメータがあります。それについて何も悪いことはありません。
• 幅の広いテーブルに遭遇した場合、一時停止してスキーマを確認してください（30が特に広いわけではありません）。ライフノーマライズから始まったテーブルを見つけることは珍しいことではありませんが、怠lazや無秩序によって認識を超えて拡大しています。
• 一連のパラメーターをCSVリストまたはXMLとして渡すことも簡単に検討しないでください。クエリオプティマイザーをブラインドし、時間または労力をほとんどまたはまったく節約します。
• 多数のパラメータを使用してプロシージャを呼び出すために、クライアントコードを手動でクランクしないでください。T4テンプレートやCodeSmithなどのコード生成ツールが役立ちます。

Joe Celkoは長いパラメーターリストの擁護者であり、この 2部構成の記事で詳しく説明しています。

最も簡単な答えは、長いパラメーターリストを使用して、プロシージャ本体内でリストと派生テーブルを作成することです。SQLサーバーは最大2100個のパラメーターを処理できますが、実際の目的にはこれで十分です。SQL Serverは、実際にはこの点で弱者です。DB2; 32Kパラメーターを渡すことができます。Oracleは64Kのパラメーターを持つことができます。

...長いパラメーターリストは、単純な古いパラメーターで構成されているため、出力だけでなく入力にも使用できます。また、オプティマイザーが使用する1つのステートメントに含まれています。

これらの手法は常に最良のソリューションだと思いますか？もちろん違います。SQLにはそのようなものはありません。しかし、適切な問題が発生した場合は、見る価値があります。