我应该如何重命名许多存储过程而不破坏内容？

Question

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

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

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

注意：我不认为我的问题与这个问题重复因为后者仅涉及数据库内的重命名。

Answer 1

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

这里您真正需要的是一种缓慢且增量地重命名存储过程的方法。
我当然不会进行全局查找和替换。

相反，当您识别小块功能并了解过程之间的关系时，您可以重构小块。

不过，此过程的基础是数据库的源代码控制。
如果您不像正常代码一样管理对数据库的更改，您将遇到严重的麻烦。

看看 DBSourceTools。 http://dbsourcetools.codeplex.com
它专门设计用于帮助开发人员将他们的数据库置于源代码控制之下。

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

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

Answer 2

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

Answer 3

您可以分阶段进行更改：

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

Answer 4

您可以将存储过程的“核心”移动到满足新命名约定的新存储过程，然后将原始存储过程保留为委托给新存储过程的外壳/包装器。
您还可以添加一个“审核”表来跟踪旧的包装器 SPROC 何时被调用 - 这样您就会知道旧的 SPROC 没有依赖项，并且可以安全地删除旧的 SPROC（另外，请确保它是不仅仅是使用数据库的“您的应用程序” - 例如跨数据库连接或其他应用程序）

这会带来很小的性能损失，并且不会真正为您带来那么多（除了能够更轻松地“找到”您的新存储过程之外）

Answer 5

您至少需要在两个领域处理这个问题：应用程序和数据库。可能还有其他区域，您必须小心不要忽视它们。

应用程序

未来项目的良好实践

它有助于抽象您的存储过程。在我们的应用程序中，我们将所有存储过程包装在一个巨大的类中，我可以像这样进行调用：

Dim SomeData as DataTable = Sprocs.sproc_GetSomeData(5)

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

没有抽象

如果没有这种抽象，您只需对存储过程名称执行“在文件中查找”(Cntl+Shift+F)，然后如果结果看起来正确，则打开文件并查找/替换所有的情况。

Sql Server

不要信任查看依赖关系

在 SQL Server 端，理论上在 MSSMS 2008 中您可以右键单击存储过程并选择“查看依赖关系”。
应该向您显示数据库中使用存储过程的所有位置的列表，但是我对此功能的信心非常低。在 SQL 2008 中可能会更好，但在以前的版本中肯定有问题。

查看依赖关系伤害了我，需要时间来治愈。 :)

把它包起来！

你最终不得不保留旧存储一段时间。这就是为什么重命名存储过程是一个这样的项目的主要原因——它可能需要一个月的时间才能最终完成。

首先用一些简单的 TSQL 替换其内容，这些 TSQL 使用相同的参数调用新的存储过程，并编写一些日志记录，以便在一段时间过去后，您可以判断旧的存储过程是否实际上未使用。

最后，当您确定旧存储过程未使用时，将其删除。

其他区域？

还可能有很多其他区域。我首先想到的是报告服务。 SSIS 包。使用保留旧存储过程并重新路由到新存储过程（如上所述）的技术将帮助您知道是否错过了任何内容，但它不会告诉您错过了什么。这会导致很多痛苦！

祝你好运！

Answer 6

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

使用全局搜索和替换（但查看每个建议的替换）来尽量避免丢失任何实例。如果您的应用程序结构良好，那么每个存储过程实际上应该只有 1 个地方被调用。

Answer 7

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

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

这使得管理应用程序可能对数据库服务层进行的所有潜在调用变得更加容易。

Answer 8

恐怕对源代码和其他数据库对象进行搜索会有点乏味。

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

如果您有一个支持使用正则表达式搜索文件的工具（我已使用 RegexBuddy .

如果您只想涵盖可能错过的可能性，您可以将所有以前的存储过程保留一个月，然后让它们记录 自定义 SQL 跟踪事件，其中 APP_NAME( )、SUSER_NAME() 以及您认为有用的任何其他信息，然后让它调用重命名的版本。然后设置跟踪来监视此事件。

Answer 9

如果您使用到数据库、存储过程等的连接，您应该创建一个服务类来委托这些方法。

这样，当您的数据库、SP 等中的某些内容发生变化时，您只需更新您的服务类，并且所有内容都不会被破坏。

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

Answer 10

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

http://www.sqldigger.com/

SQL Server（从 SQL 2000 开始）对其自身的依赖关系了解甚少，因此需要搜索脚本文本来查找依赖项，这些依赖项可能是其他存储过程或动态 sql 的子字符串。

Answer 11

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

   选择 OBJECT_NAME(m.object_id), m.*
     来自 SYS.SQL_MODULES m
    WHERE m.definition LIKE N'%my_sproc_name%'
   

   • SQL 需要在每个可能引用的数据库中运行。
   • syscomments 和 INFORMATION_SCHEMA.routines 具有 nvarchar(4000) 列。因此，如果在位置 3998 处使用“mySprocName”，则不会找到它。 syscomments 确实有多行，但 ROUTINES 会截断。 如果您不同意，请向 gbn 提出。
2. 根据该依赖项列表，我将创建新的存储过程，启动基础存储过程 - 那些依赖项最少的存储过程。但我会 介意不创建存储过程，并在名称前添加“sp_”前缀
3. 验证基础过程与现有过程的工作方式相同
4. 移至下一级存储过程 -根据需要重复步骤 1-3，直到处理完最高级别的程序。
5. 测试应用程序使用到新过程的切换 - 不要等到所有过程都更新后才测试与应用程序代码的交互。不需要对每个存储过程都执行此操作，但等待批量执行也不是一个好方法。

并行开发也有风险：

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

Answer 12

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

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

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

Answer 13

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

Enterprise Library 5 DAAB 中的数据库访问器 - Database.ExecuteSprocAccessor

拥有类似于

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

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