在SQL Server 2005中升级存储过程

核心提示：我最近在《SQL Server 2005的变化》一文中揭示了SQL Server 2005的变化如何打破了旧有的应用程序和数据库，特别是使用被抛弃的函数的地方，在SQL Server 2005中升级存储过程，现在我将要讨论的是如何在你的移植过的数据库里面使用存储过程来充分利用这个SQL Server2005中的新函数，

我最近在《SQL Server 2005的变化》一文中揭示了SQL Server 2005的变化如何打破了旧有的应用程序和数据库，特别是使用被抛弃的函数的地方。现在我将要讨论的是如何在你的移植过的数据库里面使用存储过程来充分利用这个SQL Server2005中的新函数，而不需要打破现有的功能性。

我们假设你有一个前端的应用程序，是由不同的团队来分别写入或者管理，并且它不像后台数据库那样频繁更新。你想要在SQL Server应用程序的存储过程中进行修改以充分利用新的功能。你还想要这个过程尽量温和，这样数据库和前端应用程序就都不会突然崩溃。

例如，你想要更新存储过程来使用SQL Server 2005的T-SQL中一些新的功能，例如TRY and CATCH函数，这个函数可以让复杂的错误追踪变得简单一点。你通常会拷贝现有的存储过程到一个新的并行的存储过程里面去，然后对它进行更新，使用新的功能，然后或者在经过修改的前端应用程序版本，或者查询分析器中测试两方面的行为。

当你很自信新的存储过程的行为是正确的，并且它也准备好用在产品中，你就可以无缝的替换它，例如通过修改两个存储过程的名字，或者通过代码的拷贝。我个人倾向于修改名字，因为这可以让你对原有的代码做个备份——像你的数据库中的其它东西一样，做个备份，以防出现不可预期的问题。

这是相对标准的技术，但是我曾见过的更有意思的一个问题涉及了可选参数传递：

CREATE PROCEDURE my_procedure {其它的参数在这里}, @optionalparameter Boolean=FALSE AS If @optionalparameter=TRUE Begin {带有SQL Server 2005-特定命令的新版本的存储过程放在这里} End Else Begin {旧版本的存储过程放在这里} End

还有另外一种有用的方式来选择性的测试代码。现有的前端对存储过程的呼叫不会使用可选参数，还会执行原来的代码。你可以在这里使用新的前端代码来测试存储过程，然后优雅地更新对现有存储过程的参考。因为参数是可选的，所有现有的对存储过程的呼叫(例如那些没有参数的呼叫)都会像以前一样准确地传递过去。

如果你不能添加新的存储过程，但是可以修改现有的存储过程的话，还有一种在这种限制下的好办法。当没有保留历史遗留代码的时候，你可以在存储过程中逐步淘汰IF。最后，在存储过程和你的前端代码中逐渐放弃可选参数。