存储过程维护

Question

在SQL Server ...

我应该保持通过对象broswer在查询分析器中的存储过程，或作为外部文本文件，为什么？

Answer 1

...对源代码控制中的文本文件的另一投票。

• 一个巨大的好处是修订历史记录。比较版本可以让您深入了解问题，并节省您数小时的调试时间，特别是“我想知道他们为什么要这么做”的多种调试方法。
• 如果您有在你没有别人看见一个数据库实例的问题，您可以导出存储过程中的问题，把它比作什么在源头控制，并确保你跨实例一致。
• 这使得代码部署到一个新的数据库实例更易于控制。比如，你可以写一个Ant任务审计数据库模式，并有一个运行的程序，创建代码，在这个过程中的一个步骤的任务。
• 您可以查看过程源而无需连接到数据库。这在恢复场景中可能特别有用。
• 它强制执行的，而不是让你的团队在GUI工具一次性的新变化，顺应脚本可用的纪律。 GUI工具改变了工作，但如果没有在脚本中捕获，它们将永远丢失。

Answer 2

外部文本文件可以放在源代码控制中，所以这是一个更好的解决方案。版本控制数据库很困难，这是让数据库与依赖它的所有应用程序保持同步的一个重要步骤。

微软的Visual Studio 2008的数据库版做这事，允许比数据库脚本，而且设施仅有版本控制部署在一个单一的步骤，单元测试，以及其他有趣的东西更多。

Answer 3

一旦你的系统变得足够大，使用对象浏览器找到你的存储过程是很痛苦的（和它不会做使他们非常排序的一个很好的工作）。虽然我经常喜欢使用对象浏览器，但我可能会建议其他人从外部文件开始，这样您就可以从一开始就对它们进行源代码控制。

Answer 4

有一个工具可以定期提取存储过程的文本并将它们存储在源代码管理中。

这样，你就拥有了两全其美。您的文本文件存在并处于源代码管理中，您可以保证它们尽可能地保持最新。如果有人在你不知情的情况下改变你的存储过程（作为一个我曾经倾向于做的老板），你会很快以“最近的变化”的方式看到它。

Answer 5

要么。

的源代码控制外接文件提供一个很好的感觉，但数据库对象不能被控制或锁定或签出像“正常”的源文件。但是，这是一个很好的纪律。

如果你有强大的生产控制，良好的流程和代码差异的工具，然后在对象浏览器管理，对小规模的项目可行的，因为你总是可以发现差异，很容易重新设置。

我希望你不要在生产对象浏览器的意思是......

Answer 6

很多可以依赖于SQL Server的版本，您正在使用，以及如何重要的是它回滚到以前版本的SQL 。

我发现，与SQL Server 2005+，它更容易维护他们在SQL Server Management Studio中，作为其全部集成到.NET框架。

如果您定期备份数据库，我认为将备份存储为外部文件是浪费时间。

当然，我完全理解人们想使用类似SourseSafe作为历史备份额外的外部来源。