存储过程应该是多少还是重点？

Question

您应该如何制作存储过程？他们应该被视为“一击”还是镜像更常用？请考虑以下情况：

1

• FindUser（用户名，...）

  存储过程将用户ID返回给调用者

• FindItem（itemname，...）

  商店程序会将商品ID重新发送给来电者

• AddOrder（userid，itemid，...）

  然后可以将返回的id传递给第三个存储过程

2

• AddOrder（用户名，项目名称，...）

这里，id的查找是在存储过程

中完成的

是否有首选/推荐方式？谢谢你的想法。

Answer 1

我认为存储过程应该用于数据密集型业务逻辑，其中计算可能在应用程序中过于强大。

具有复杂的sp，将计算放在数据库层，避免大量数据集传输到应用程序。这也将允许程序员在不必重新编译的情况下更改功能，但可以减慢调试速度。

我发现使用sps只是通过密钥（例如用户ID）检索对象（例如用户）的数据，或者使用自动生成的数据访问层来找到特定字段，我们发现很多时候，每个对象生成了很多sps。

我们尝试将sps限制为报告数据集和复杂数据计算/操作。

Answer 2

不要陷入这样的陷阱：认为必须管理/维护许多简单的过程比仅仅是一些复杂的过程更困难。我总是发现，每当我们尝试使一个过程做多个事情而不是一个有针对性的事情时，调试和测试就变得非常困难。

你说“存储过程应该很多还是重点？”，我建议这是一个不正确的比较。

如果你有很多存储过程，那么它们会更加集中，因为它们会更小并且做得更少。也许你真的想要问“许多专注的存储过程，或更少的更广泛的存储过程？”

诸如db ghost等工具也应该用于控制存储过程代码（和模式），因此您可以像处理任何其他代码一样对待它。有了这个，许多小程序的管理就更容易了。

这实际上只是将关注点分离的核心良好设计实践应用于您的“数据库代码”以及所有其他代码。

正如另一个答案所说，我喜欢使用存储过程来“压缩”您的数据，尽可能接近数据库，例如在报告过程中。这是由于性能原因，即让数据库做它擅长的事情。

然而，当涉及到许多其他类型的“业务逻辑”时，我们通常会尝试将其保留在存储过程中，并且在普通代码中我们有更好的调试和测试工具。

Answer 3

我个人会选择多个oneHit SP，因为创建一个大块的SP会增加错误处理的复杂性。无效的项目名称，但有效的用户名等...另一方面，人们可能会争辩说，从性能的角度来看，大块的可能更好。

我会选择多个，但我也很喜欢其他想法......

+1问题。

ķ