多个相互依赖的存储过程。应该在代码或存储过程中完成？答案

【问题标题】：multiple Stored procedures dependent on one another. Should be done in code or Stored procedure?多个相互依赖的存储过程。应该在代码或存储过程中完成？
【发布时间】：2012-12-26 21:11:15
【问题描述】：

我试图决定是否应该尝试将我的存储过程整合到我的数据库中或编写代码。基本上，我有一个表（分析），它有一个指向另一个表（Urls）的外键。当用户访问某些页面时，第一个表将尝试创建条目。在该表的存储过程（Analytics）中，如果该行已经存在，它将更新，否则创建该行。我正在考虑发回 ID，然后更新另一个表。或者我可以在同一个存储过程中更新另一个表。在同一页面点击中还会有 2 个其他表执行类似的操作。

我很矛盾，因为我的面向对象方面希望每个存储过程只做一件事，但我知道这将发生在每个页面上，并且希望尽可能从优化中得到什么。

对多次调用与一次调用数据库的速度差异有何看法。真的会出问题吗？

【问题讨论】：

标签： .net sql c#-4.0 optimization

【解决方案1】：

对多次调用与一次调用数据库的速度差异有何看法。真的会出问题吗？

是的，当然可以。

对于每个数据库调用，都有连接开销、网络 IO 开销以及数据库服务器和客户端的额外工作——这些都很慢。此外，以这种方式构建存储过程很容易将您带到N+1 problem。

一般来说，如果您可以构造事物，以便在 one 查询中尽可能多地执行操作，那么您的数据库和应用程序会更快、响应更快，因为昂贵且缓慢的资源使用会保持在最低限度。

【讨论】：

谢谢奥登。因此，最好的方法是摆脱面向对象的思维，让存储过程一次性为您完成所有插入和更新，而您所说的是否正确？更少的通话/开销。我想我唯一担心的是，虽然它的开销更少..如果存储过程做了很多事情，它是否变得更难阅读以及更难命名？另外，您对调用其他存储过程以保持事物分离的存储过程有何看法？
好吧，您需要考虑可读性以及 SP 的选项做得太多。这里没有一个正确的答案——你需要权衡一下，看看它们在生产中的表现如何。像 CQRS 这样的模式可以让这方面的事情变得更简单。
至于 SP 调用 SP - 从长远来看，这可能会变成一个纠结的可怕混乱（你允许多少级别？你如何确保对一个 SP 的更改不会波及？等等。 .).
让 SP 调用 SP 的另一件事是，虽然您可以这样做，但存在一些限制。首先，如果您的深度超过 2 并且每个 SP 返回一个您想要通过Insert Into ... Exec 捕获的结果集，那么在第二级之后将失败。出于某种原因，MS SQL 不允许这样做。澄清一下，您可以让 SP A 使用 Insert Into ... Exec B，但您不能让 SP B 使用 Insert Into ... Exec C。