存储过程的版本更改

Question

我有一个非常依赖存储过程的应用程序（SQL 2005/2008）。我们正在做一个小修改，修改这些存储过程中的25-35个。该应用程序使得两个版本的存储过程都必须可用。

这是应用程序的主要版本4，通常我们已经能够完全修改数据结构以适应每个新版本。但是在这种情况下，我们不能这样做。

以下是我提出的两个选项

1. 制作每个存储过程的“2”版本。如果我有一个名为getUser的过程，请创建一个getUser2。这样做的缺点是，每次版本更改时，存储过程数将呈指数级增长

2. 将@version参数添加到默认为v1的每个存储过程。这将使存储过程的数量减少，但会使每个存储过程膨胀

有人对此有任何想法吗？还有其他聪明的想法吗？

科迪

Answer 1

我将借此机会从存储过程转移到ORM或其他方法。您提出的两个解决方案都需要某种代码更改来决定使用哪个存储过程。相反，我决定是使用存储过程还是ORM。我还会制定逐步淘汰大部分存储过程的计划。

在我的职业生涯中，我看到了很多糟糕的代码并搞砸了系统，但是没有什么可以破坏我的希望，就像在存储过程列表中看到GetItemFromLots_2_Temp_2一样可以挽救一个项目。与多个存储过程相比，多种方法更漂亮，更易于维护。

（对于喜欢存储过程的其他人。我不是说他们很糟糕。我确信有一些聪明的方法可以使用存储过程处理这类事情但是，如果使用这种方法，这个问题不会被问到。）

Answer 2

修改现有的存储过程，以便有条件地执行新逻辑，只有当在新逻辑应该执行的那些循环下调用proc时......如果新的proc将具有稍微不同的接口（sProc的集合）参数）然后你可以使它们成为可选的并使用参数的存在或不存在开关来控制在proc中执行哪些代码块...

当不再需要旧逻辑时，您只需将其从sProcs

中删除即可

Answer 3

我不会创建两个不确定的文件。

也许在您的源代码管理中，您应该创建所有版本的分支，然后使用您的下一个版本创建一个新分支，然后您可以将两个分支作为单独的文件夹包含在您的系统中，并让您的业务逻辑指向正确的位置。

这个解决方案可能有点草率，但我认为这是几个邪恶中较小的一个。

无论如何，在我看来，实际版本化存储过程代码是必须的。

Answer 4

我会建议你提供的第二个选项。使用版本参数。这就是Web服务的作用，因此它们不会破坏很久以前使用API​​开始的应用程序代码，但API会在某些时候更新。

我敢打赌，两个版本之间存在一些相同的逻辑，你可以将它们抽象到proc的底部或其他东西。或者可能为公共元素创建函数，并在大IF / SWTICH块中调用这些函数。

Answer 5

我会选择两个文件选项，原因如下：

• 签名，即参数数量可以在不同版本之间更改
• 每个存储过程都会更简单，因此所有条件代码错误的可能性更小

Answer 6

我们曾经在我的公司广泛使用存储过程，但是（最近）已经（大部分）从最近的ORM转移到ORM。

我们仍然使用它们，我们的版本控制与以前一样：每次我们修改剩余的存储过程（只有少数人有权做），我们保存SQL，并存储我们的版本控制中的.sql文件。

它不完美，我们在源代码控制和代码文件之间失去了很多集成（因为没有SQL服务器集成到TFS中），但它总比没有源代码控制好。

编辑 - 当然，这只有在您不再需要使用旧版本的存储过程时才有效，因为它将不再以可运行的形式存在。

Answer 7

另一个有趣的方法是将存储过程的所有代码存储在数据库表中，以及代码的版本。然后你有一个处理请求的“前端”proc，然后根据版本动态创建一个proc并执行它。然后它可以在完成后删除proc。

只是一个关于墙的建议，但可能会为你工作。