我有一个非常依赖存储过程 (SQL 2005/2008) 的应用程序。我们正在做一个小更新，将修改这些存储过程中的 25-35 个。该应用程序必须提供两个版本的存储过程。
这是应用程序的主要版本 4，通常我们已经能够完全修改数据结构以适应每个新版本。但是在这种情况下，我们不能这样做。
这是我想出的两个选项
为每个存储过程制作一个“2”版本。如果我有一个名为 getUser 的过程，请创建一个 getUser2。这样做的缺点是存储过程的数量会随着每个版本的变化而呈指数增长
为每个默认为 v1 的存储过程添加一个 @version 参数。这会减少存储过程的数量，但会使每个存储过程膨胀
有人对此有任何想法吗？还有其他聪明的想法吗？
科迪
【问题讨论】：
标签： sql-server-2005 database-design architecture stored-procedures
我会借此机会从存储过程转移到 ORM 或其他方法。您提出的两种解决方案都需要进行某种代码更改来决定使用哪个存储过程。相反，我会让它决定是使用存储过程还是 ORM。我还会制定计划逐步淘汰大部分存储过程。
在我的职业生涯中，我见过很多糟糕的代码和混乱的系统，但没有什么能像在存储过程列表中看到 GetItemFromLots_2_Temp_2 一样让我希望可以挽救一个项目。多个方法比多个存储过程更漂亮，更易于维护。
（对于喜欢存储过程的其他人。我并不是说它们不好。我相信有一些聪明的方法可以使用存储过程来处理这种事情，但是，如果使用这种方法，这个问题不会被问到。）
【讨论】：
修改现有的存储过程，以便有条件地执行新逻辑，仅当在应该执行新逻辑的情况下调用 proc 时...如果新 proc 的接口略有不同（sProc 集参数）然后您可以将它们设为可选并使用参数的存在与否作为开关来控制在过程中执行哪些代码块......
当不再需要旧逻辑时，您可以简单地将其从 sProcs 中删除
【讨论】：
我肯定不会创建两个不同的文件。
也许在您的源代码控制中，您应该为所有版本创建一个分支，然后为您的下一个版本创建一个新分支，然后您可以将两个分支作为单独的文件夹包含在您的系统上，并让您的业务逻辑指向正确的位置。
这个解决方案可能有点草率，但我认为它是几个弊端中较小的一个。
无论如何，在我看来，对存储过程代码进行实际版本控制是绝对必要的。
【讨论】：
我会建议您提供的第二个选项。使用版本参数。这就是网络服务所做的，因此它们不会破坏很久以前开始使用 API 但 API 会在某个时候更新的应用程序的代码。
我敢打赌，两个版本之间存在一些相同的逻辑，您可以将其抽象到 proc 的底部或其他东西中。或者可能为公共元素创建函数并在您的大 IF/SWTICH 块中调用这些函数。
【讨论】：
我们曾经在我的公司广泛使用存储过程，但最近（大部分）已经从它们转向 ORM。
我们仍然使用它们，并且我们的版本控制与以前相同：每次我们修改保留的存储过程（只有少数人有权这样做）时，我们都会关闭 SQL，并存储.sql 文件在我们的版本控制中。
它并不完美，我们失去了很多源代码控制和代码文件之间的集成（因为 TFS 中没有 SQL 服务器集成），但总比没有源代码控制要好。
编辑 - 当然，这仅在您不再需要使用旧版本的存储过程时才有效，因为它将不再以可运行的形式存在。
【讨论】：
另一种有趣的方法是将存储过程的所有代码连同代码的版本一起存储在数据库表中。然后你有一个处理请求的“前端”过程，然后，根据版本，动态创建一个过程并执行它。然后它可以在完成后删除 proc。
只是一个现成的建议，但可能对你有用。
【讨论】：
出于以下两个原因，我会选择两个文件选项：
【讨论】：