你应该如何通用你的存储过程？他们应该被视为“一击”还是镜像更普遍的用途？考虑以下情况：存储过程应该很多还是集中？
1.
FindUser（用户名，...）
存储过程返回的用户ID给调用者
的FindItem（ITEMNAME，.. ）
存储过程将该物品ID重新发送给呼叫者
AddOrder（用户ID，为itemid，...）
返回然后IDS可以被传递到所述第三存储过程
2.
这里，ID的查找，在存储过程中完成的
是否有首选/推荐的方式？谢谢你的想法。
不要陷入这样一种想法，即必须管理/维护许多简单的特效比较困难，只有少数复杂的特效。我总是发现，无论何时我们试图让一个过程执行多个事情而不是一个重点事件，调试和测试变得更加困难。
你说“应该存储过程很多还是集中？”，我会建议这是一个不正确的比较。
如果你有很多存储过程，那么它们会更加专注，因为它们会更小，更少。也许你的意思是问“许多重点存储过程，或更少更广泛的存储过程？”
还应该使用db ghost等工具来控制存储过程代码（和模式），以便像处理其他代码一样对待它。有了这个，许多小程序的管理就更容易了。
这实际上只是将关注点分离的核心优秀设计实践应用到您的“数据库代码”以及所有其他代码。
正如另一个答案也说，我是一个使用存储过程来“紧缩”你的数据，尽可能靠近数据库，如报告特效的粉丝。这是由于性能的原因，即让数据库去做它擅长的事情。
但是，当涉及到很多其他类型的“业务逻辑”时，我们通常会尽量避免存储过程中的代码，并且在普通代码中我们有更好的调试和测试工具。
就我个人而言，我会选择多个oneHit SP，因为创建一个矮胖的增加了很多错误处理的复杂性。无效的商品名称，但有效的用户名等......另一方面，人们可能会认为，从性能角度来看，矮块可能会更好。
我会去多者，但我interessted过什么其他的想法都是围绕...
+1的提问。
ķ
多个似乎是最好的前进方向。感谢您的反馈意见。 – DanDan 2009-09-23 15:06:27
我相信，存储过程应该用于数据密集型业务逻辑，这里的计算可能过于性能在应用密集。
拥有复杂的sp，将计算放在数据库层，避免大量的数据集传输到应用程序。这也将允许程序员在无需重新编译的情况下更改功能，但可能会减慢调试速度。
我发现使用sps仅仅通过键（例如userid）或特定字段检索对象（例如用户）的数据主要是使用自动生成的数据访问层发现的，而且我们发现很多次，每个对象都会生成许多sps。
我们试图限制sps报告数据集和复杂的数据计算/操作。
感谢您的意见。 – DanDan 2009-09-23 15:05:34
谢谢你精心设计的答案。最后一段让我深信不疑。我将为存储过程提供更多更小的方法。 – DanDan 2009-09-23 15:09:42