任何人都可以提供一些真实示例,说明如何最好地将视图、存储过程和函数的脚本文件保存在 SVN(或其他)存储库中。
显然,一种解决方案是将所有不同组件的脚本文件放在一个目录或多个目录中,并简单地使用 TortoiseSVN 等将它们保存在 SVN 中,然后每当要进行更改时,我将脚本加载到 Management Studio 等中.我真的不想要这个。
我真正喜欢的是某种可以定期(每晚?)运行的批处理脚本,它将导出在给定时间范围内更改的所有存储过程/视图等,然后将它们提交给 SVN。
想法?
任何人都可以提供一些真实示例,说明如何最好地将视图、存储过程和函数的脚本文件保存在 SVN(或其他)存储库中。
显然,一种解决方案是将所有不同组件的脚本文件放在一个目录或多个目录中,并简单地使用 TortoiseSVN 等将它们保存在 SVN 中,然后每当要进行更改时,我将脚本加载到 Management Studio 等中.我真的不想要这个。
我真正喜欢的是某种可以定期(每晚?)运行的批处理脚本,它将导出在给定时间范围内更改的所有存储过程/视图等,然后将它们提交给 SVN。
想法?
对我来说,听起来你不想正确使用修订控制。
显然,一种解决方案是将所有不同组件的脚本文件放在一个目录或多个目录中,然后简单地使用 TortoiseSVN 等将它们保存在 SVN 中
这是应该做的。您将拥有正在处理的本地副本(开发新的、调整旧的等),并且随着单个组件/过程/等完成,您将单独提交它们,直到您必须重新开始该过程。
仅仅因为距离上次提交已经“X”次而提交半完成的代码是草率的,并且肯定会导致其他使用存储库的人感到悲伤。
我发现最好像对待任何其他可编译代码一样对待存储过程:代码存在于存储库中,您检查它以进行更改并将其加载到您的开发工具中以编译或部署代码。
您可以创建一个批处理文件并安排它:
请注意:尽管您将拥有受源代码控制的对象,但您不会拥有数据或其进程(是重命名的字段,还是 1 个新字段和 1 个已删除?)。
这种方法非常适合维护变更历史。但是,当然,您永远不应该自动提交到“生产构建”(除非您喜欢损坏的构建)。
尽管您没有要求它:这种方法也不会生成一组将升级当前数据库的脚本。您将只有初始创建脚本。记录数据进程和创建升级脚本超出了基本的源代码控制系统。
我会为此推荐Redgate SQL Compare - 它允许您比较数据库版本并生成更改脚本 - 它也很容易编写脚本。
根据您扩展的问题,您真的想使用 DDL 触发器。查看这篇文章,详细介绍如何为您的数据库创建变更日志系统。
不确定您的价格范围,但DB Ghost可能是您的选择。
我不为这家公司工作(或拥有该产品),但在我研究同一问题时,该产品看起来很有前途。
我应该更具描述性。有问题的数据库是用于内部 ERP 系统的,因此我们没有很多版本的数据库,只有生产/测试/开发。当我们完成更改请求、一些新奇特的功能或其他东西时,我们只需执行一个脚本或一系列脚本来更新测试数据库上的相关过程,如果一切顺利,那么我们对生产也做同样的事情。
所以我并不真正追求完整的模式脚本本身,只是可以随着时间的推移跟踪对存储过程的各种编辑。例如, PROCESS_INVOICE 会做一些事情。它在三月份以一些小的方式进行了更新。在 5 月之后的某个时间,人们发现在极少数情况下,客户会收到双重发票(或其他一些疯狂的极端情况)。我希望能够看到随着时间的推移这个过程发生了什么。目前这里设置开发环境的方式我没有,我正在尝试改变。
我可以推荐 DBPro,它是 Visual Studio Team Edition 的一部分。几个月来一直使用它来存储 Team Foundation Server 中数据库的所有部分以及部署和数据库比较等。
当然,正如其他人提到的,它确实取决于您的环境和价格范围。
我编写了一个实用程序,用于将我的数据库的所有相关部分转储到我使用 SVN 的目录结构中。我从来没有尝试将它合并到管理器中,但是,如果你有兴趣,它就在这里:http ://www.relucantdba.com/dbas-and-programmers/sqltools/svnforsql2005.aspx
它是免费的,而且因为我经常运行它,所以你知道任何错误都会很快得到修复。
您可以随时尝试将 SourceSafe 与 SQL Server 集成。这是一个快速入门:链接。要使用它,您必须拥有 Managment Studio Developers Edition。