Sql server 2005 关于嵌套存储过程

具有嵌套存储过程（意味着在另一个存储过程中调用存储过程）是一种好做法吗？嵌套存储过程时，是否有应遵循的预防措施？有没有一个允许的限制，有多少人可以巢内

---

感谢期待

最大嵌套级别为32。

---

在我看来，这样做的真正缺点是，SP依赖于另一个SP的情况很快就会失控。风险在于，您在一个SP中更改了一些对另一个SP具有不可预见影响的内容。一旦这些内容多次困扰您，您在更改SP之前会犹豫，并考虑创建一个新的SP，该SP的功能几乎完全相同过了一段时间，没有人知道SP为什么在那里，或者它是否正在实际使用。很容易变得非常混乱。

是的，嵌套的级别有限制。从：

您最多可以嵌套32个级别的存储过程[…]

这种限制的存在可能意味着嵌套存储过程调用过多并不是一件好事。然而，在我看来，最大级别似乎足够大，人们不必担心嵌套调用，比如5级左右的深度

事实上，我从来没有听说过在设计中使用嵌套调用会带来任何类型的缺点，我也没有经历过相互调用存储过程的任何实际缺点。相反，我认为，分解服务器端代码可以使设计更加灵活。或者，如果没有其他功能的话，它至少允许您通过将较大的存储过程拆分为大小适中（逻辑上可能完整）的单元，使存储过程的代码更易于管理

---

我的意思不是说您应该不惜任何代价考虑存储过程，我只是认为，如果嵌套过程更适合您的设计，那么就没有任何问题。

对不起，您的观点是什么？我只是不确定。是嵌套存储过程还是“几乎重复”存储过程使事情变得混乱？@AndriyM-问题是，我认为您应该小心使用SP来实现这一原则。在某些情况下，让一个SP具有定义良好的任务，可以在其他SP中重用，当然是有意义的，但是。。。嵌套SP（在我看来）很难维护。忘记回答你的问题了。“嵌套”和“几乎重复”都会让事情变得一团糟。因此，在我工作的项目中，我们在DB/SP中没有（几乎）业务规则，所有不受约束的内容都在middletire中控制。我现在明白了，非常感谢！我想我可以同意，维护SP（特别是当有很多SP时）比维护大致相同数量的客户端代码更难。这是一种情况，即拥有良好且及时更新的产品文档尤为重要，尤其是当维护SPs的人员不止一人时。