我应该跨嵌套存储过程共享临时表吗？答案

【问题标题】：Should I share temp tables across nested stored procedures?我应该跨嵌套存储过程共享临时表吗？
【发布时间】：2014-01-06 15:57:12
【问题描述】：

我目前正在尝试清理一些存储过程。其中大约有 20 个看起来非常相似并且做许多相同的事情，但采用的参数和过滤数据略有不同。

在大多数情况下，所有存储的过程都首先将一些数据加载到一个或两个表变量中（这通常是过程不同的地方）。之后，每个存储过程的所有代码或多或少都相同。他们执行一些日志记录并应用一些额外的常用过滤器。

我想至少将常见的部分转入存储过程，这样代码会更容易阅读，我们不必打开 20 个过程来更新同一行 sql，但是使用表变量会阻止它。我们使用的是 Sql Server 2005，据我所知，我们不能在存储过程中使用表值参数。

但是，我们可以将所有表变量更改为临时表，并在新的公共存储过程中引用它们。我假设这是一种相当普遍的做法，但想知道这是否真的是个好主意。

在嵌套的存储过程中，我是否应该假设已经在其他地方创建了一个临时表并且只是查询它？我可以测试该表是否存在，但如果不存在怎么办？ 2005 年有什么好的替代方案吗？对于打开其中一个嵌套存储过程并看到在其他地方创建的临时表的其他开发人员是否感到困惑？我只需要添加大量信息丰富的 cmets 吗？

【问题讨论】：

在你的嵌套过程中；可以肯定的是，您可以检查表是否存在。如果不存在，则 RAISERROR 带有一些错误消息。由于您使用的是 SS2005，因此 #temptable 将是您的选择。为易于阅读而对代码进行注释绝不是一种糟糕的做法。
对于旨在嵌套且不应单独调用的过程是否有任何命名约定？我知道应该添加 cmets，但我见过很多代码更改但没有人更新注释以反映它的实例。当然，这是我们可以通过良好实践来管理的事情，但是任何有助于提高可读性和一致性的东西都是受欢迎的。我想临时表可能是我目前唯一的选择。
谈论命名约定；遵循更适合您的组织的任何约定（我只是为 SP 提供了一个正确的名称，以反映 SP 的目的）。如果发生代码更改，则相应地更改注释是开发人员的责任。除此之外，无论你在做什么在我看来都是正确的。
酷，我希望是这样。感谢您的意见，拉胡尔。

【解决方案1】：

在您的嵌套过程中；可以肯定的是，您可以检查表是否存在。如果不存在，则 RAISERROR 带有一些错误消息。由于您使用的是 SS2005，#temptable 将是您的选择。为易于阅读而对代码进行注释绝不是一种糟糕的做法。

谈论命名约定；遵循更适合您的组织的任何约定（我只是为 SP 提供了一个正确的名称，以反映 SP 的目的）。如果发生代码更改，则相应地更改注释是开发人员的责任。除此之外，无论你在做什么，在我看来都是正确的。

【讨论】：

@MartinSmith，想把它作为一个答案，但通过评论对话让它起作用了。此外，SO中有很多这样的评论只回答（我个人不喜欢因为对未来的读者有用的可能性很小），但从未见过有人提议像你一样做出回答（我真的很感激）。不确定我应该遵循的实际约定是什么（永远不要只发表评论或回答什么？）。无论如何，撤消我的评论并将其作为答案。谢谢你的建议。现在给 +1 ... LOL :)