有多少存储过程参数太多？

我刚刚开始在SQL Server 2008中编写存储过程，并且有30多个参数。我从来没有写过超过10个参数，而这让我开始思考...什么时候有太多参数？

对于背景...这个程序基本上将INSERT单列成一个单一的表。也将有一个非常相似的地方。尽管稍小；对同一张表执行UPDATE的版本。大多数列相对较小，混合使用int和字符串（varchar(200)）。

有什么问题；是好是坏; 一个具有大量参数的程序，我应该开始考虑其他模式的门槛是什么？

有问题吗？我不会争论。

• 限制为2100个参数。IIRC自SQL2000起已经是2100，但是文档错误提示它是1024。
• 如果表有1000列（例如，由于使用Sharepoint式稀疏列的方式），并且您要通过存储过程强制进行访问，则您的插入proc可能有1000个参数。没有错。
• 遇到宽表（不要特别宽30）时，请暂停以检查架构。找到从生活正常化开始的桌子并不少见，但是由于懒惰和/或无瑕疵已经超出了人们的认识。
• 甚至不要简单地考虑将一组参数作为CSV列表或XML传递。盲目优化查询，节省很少甚至没有时间或精力。
• 不要用手摇客户机代码来调用带有大量参数的过程。诸如T4模板或CodeSmith之类的代码生成工具可以解救。

Joe Celko倡导长参数列表，他在这篇 分为两部分的文章中对此进行了详细介绍：

最简单的答案是使用一个长参数列表在过程主体内部构造列表和派生表。SQL Server最多可以处理2100个参数，对于实际用途而言，这些参数应该绰绰有余。在这方面，SQL Server实际上是个w弱。DB2；可以传递32K参数。和Oracle可以有64K参数。

...较长的参数列表由简单的旧参数组成，这意味着它们既可用于输出也可用于输入。它也包含在一条语句中，供优化程序使用。

我认为这些技术将永远是最好的解决方案吗？当然不是。SQL中没有这样的东西。但是，当您遇到适当的问题时，值得一看。