如何在不破坏内容的情况下重命名许多存储过程？

Question

我的数据库多年来已经有几个连续的维护者，并且可能已经存在的任何命名准则都被忽略了。

我想将存储过程重命名为一致的格式。显然我可以在SQL Server Management Studio中重命名它们，但是这不会更新后面的网站代码中的调用（C＃/ ASP.NET）。

我能做些什么来确保所有调用都更新为新名称，而不是在代码中搜索每个旧的过程名称？ Visual Studio是否能够重构此类存储过程名称？

NB我不相信我的问题是this question的重复，因为后者仅仅是在数据库中重命名。

Answer 1

您可以分阶段进行更改：

1. 以新名称将存储过程复制到新存储过程。
2. 更改旧存储过程以调用新存储过程。
3. 当您更改网站中的所有代码时，将日志记录添加到旧存储过程。
4. 过了一段时间，当您没有看到对旧存储过程的任何调用，并且您很高兴您在网站上找到了所有调用，您可以删除旧的存储过程并进行日志记录。

Answer 2

您可以将SPROC的'guts'移动到符合新命名约定的新SPROC，然后将原始sproc保留为委托给新SPROC的shell / wrapper。 您还可以添加一个“审计”表来跟踪旧包装器SPROC的调用时间 - 这样您就会知道旧的SPROC没有依赖关系，并且可以安全地删除旧的SPROC（同样，确保它不是不只是'你的应用程序'使用数据库 - 例如跨数据库连接或其他应用程序）

性能损失很小，并不会真的给你带来太大的收益（除了能够“更容易地”找到你的新SPROCs）

Answer 3

您需要至少在两个方面处理此问题，即应用程序和数据库。也可能有其他领域，你必须小心不要忽视它们。

应用

未来项目的良好实践

它有助于抽象你的sprocs。在我们的应用程序中，我们将所有的sprocs包装在一个巨大的类中，我可以这样打电话：

Dim SomeData as DataTable = Sprocs.sproc_GetSomeData(5)

这样，代码端很好并且封装了。我可以进入Sprocs.sproc_GetSomeData并在一个地方调整sproc名称，当然我可以右键单击该方法并进行符号重命名以修复解决方案范围内的方法调用。

没有抽象

如果没有这种抽象，你可以在sproc名称中查找文件（Cntl + Shift + F），然后如果结果看起来正确，打开文件并查找/替换所有出现。

Sql Server

不信任视图依赖性

在SQL Server端，从理论上讲，在MSSMS 2008中，您可以右键单击一个sproc并选择View Dependencies。 那个应该显示数据库中使用sproc的所有地方的列表，但是我对这个功能的信心非常低。它可能在SQL 2008中更好，但在以前的版本中肯定存在问题。

查看依赖关系伤害了我，这需要时间才能愈合。 :)

包裹它！

你最终必须保持旧的sproc一段时间。这就是为什么重命名sprocs就是这样一个项目的主要原因 - 它可能需要一个月的时间来完成它。

首先用一些简单的TSQL替换它的内容，这些TSQL使用相同的参数调用新的sproc，然后编写一些日志记录，这样一旦经过一段时间，就可以判断旧的sproc是否实际未被使用。

最后，当您确定旧的sproc未使用时，请将其删除。

其他领域？

也可能有很多其他领域。想到报告服务。 SSIS包。使用保持旧的sproc并重新路由到新的sproc（上面提到的）的技术将帮助你知道你是否遗漏了任何东西，但它不会告诉你你错过了什么。这会导致很多痛苦！

祝你好运！

Answer 4

不测试应用程序中的每个路径，以确保对数据库和相关存储过程的任何调用都已更新......否。

使用全局搜索和替换（但检查每个建议的替换）以尽量避免遗漏任何实例。如果你的应用程序结构良好，那么每个存储的proc都应该只有一个地方被调用。

Answer 5

至于更改您的应用程序，我将所有存储过程作为web.config文件中的设置，因此所有名称都在一个位置，并且可以随时更改以匹配对数据库的更改。

当应用程序需要调用存储过程时，名称由web.config确定。

这样可以更轻松地管理应用程序可以对数据库服务层进行的所有潜在调用。

Answer 6

我担心你的源代码和其他数据库对象会有点乏味的搜索。

不要忘记SSIS包，SQL代理作业，Reporting Services rdl以及主应用程序代码。

如果你有一个支持使用正则表达式搜索文件的工具，你可以使用像spProc1|spProc2这样的正则表达式在源代码中同时搜索所有对象名称（我已经使用了RegexBuddy）过去）

如果您想要覆盖可能错过奇怪的可能性，您可以将所有以前的存储过程保留一个月，然后让他们使用APP_NAME(), SUSER_NAME()和其他任何信息记录a custom SQL trace event你找到了有用的，然后让它调用重命名的版本。然后设置跟踪此事件的跟踪。

Answer 7

如果使用与DB，存储过程等的连接，则应创建一个服务类来委派这些方法。

这样，当您的数据库，SP等内容发生变化时，您只需要更新服务类，并保护所有内容不被破坏。

VS有一些工具可以管理更改名称，例如重构和resharper

Answer 8

我这样做了，我在源代码中严重依赖全局搜索存储过程名称和SQL挖掘器来查找调用sql proces的sql过程。

http://www.sqldigger.com/

SQL Server（从SQL 2000开始）很难理解它自己的依赖关系，因此需要搜索脚本文本以查找依赖关系，这可能是动态sql的其他存储过程或子字符串。

Answer 9

1. 我将通过使用以下方法获取对过程的引用列表，因为SSMS依赖项不会获取动态SQL引用或数据库之外的引用。

   SELECT OBJECT_NAME(m.object_id), m.*
     FROM SYS.SQL_MODULES m
    WHERE m.definition LIKE N'%my_sproc_name%'
   

   • SQL需要在每个可以引用的数据库中运行。
   • syscomments和INFORMATION_SCHEMA.routines有nvarchar（4000）列。因此，如果在位置3998使用“mySprocName”，则无法找到它。 syscomments确实有多行但ROUTINES截断。 Should you disagree, take it up with gbn。
2. 基于该依赖项列表，我将创建新的存储过程，启动基础存储过程 - 具有最少依赖性的过程。但我mind not to create stored procedures, prefixing the name with "sp_"
3. 验证基础程序与现有程序的工作方式相同
4. 转到下一级存储过程 - 根据需要重复步骤1-3，直到处理完最高级别的过程。
5. 测试应用程序使用的切换到新过程 - 不要等到所有过程都更新以测试与应用程序代码的交互。这不需要为每个存储过程完成，但等待批量执行也不是一个好方法。

并行发展也存在风险：

• 现有代码的任何更改也需要应用于新代码。如果可能的话，在开发被冻结的区域工作或使用错误修复作为迁移到新代码的机会，而不是在两个地方应用补丁（同时最小化转换的停机时间）。

Answer 10

使用FileSeek之类的实用程序搜索项目文件夹中每个文件中的内容。不要相信Windows搜索 - 它很慢且用户不友好。

因此，如果您有一个名为 OldSprocOne 的存储过程并希望将其重命名为 SP_NewONe ，请搜索所有出现的 OldSprocOne ，然后搜索所有匹配项 OldSprocOne 以查看该名称是否尚未在其他地方使用，并且不会导致问题。然后重命名代码中的每一个匹配项。

对于大型系统而言，这可能非常耗时且重复。

Answer 11

我会更关心忽略程序的名称并用Enterprise Library Data Access Block 5替换旧的DAL

Database Accessors in Enterprise Library 5 DAAB - Database.ExecuteSprocAccessor

拥有类似

的代码

 public Contact FetchById(int id)
 {
  return _database.ExecuteSprocAccessor<Contact>
   ("FetchContactById", id).SingleOrDefault();
 }

比使用具有一致名称的存储过程具有至少十亿倍的价值，特别是如果当前代码传递给DataTables或DataSets :: shudders ::

Answer 12

我全都赞成重构任何类型的代码。

你真正需要的是一种缓慢且逐步重命名存储过程的方法 我当然不会做全球发现和替换。

相反，当您识别小部分功能并理解触发之间的关系时，您可以重新考虑小部分。

但是，这个过程的基础是数据库的源代码控制 如果您不像普通代码那样管理数据库的更改，那么您将遇到严重问题。

看看DBSourceTools。 http://dbsourcetools.codeplex.com
它专门用于帮助开发人员在源代码控制下获取数据库。

在重构之前，您需要一种可重复的方法将数据库恢复到特定状态 然后以受控方式重新应用重构的更改。

一旦你接受了这种心态，这个庞大且容易出错的任务就会变得简单。

Answer 13

这假设您使用的是SQL Server 2005或更高版本。我之前使用的一个选项是重命名旧数据库对象并使用旧名称创建SQL Server同义词。这将允许您将对象更新为您选择的任何约定，并替换代码，SSIS包等中的引用...当您遇到它们时。然后，您可以集中更新代码中的引用，而不是逐渐更新您选择的维护版本（而不是一次性破坏它们）。当您认为已找到所有引用时，可以删除同义词，因为代码将转到QA。