将SQL Server数据库对象公开为文件系统中的文件

时间:2009-10-19 02:21:32

标签: sql-server svn samba vfs

有多个文件系统

大多数版本控制工具都在本地磁盘文件系统上运行。

大多数关系数据库系统 do 的数据库对象存在于文件系统中,因为存在标识对象的文本名称,并且可以使用此名称检索或至少生成创建脚本。 / p>

但它不是本地磁盘文件系统,因此它们对CVS或SVN等工具是不可见的,这些工具严格在本地磁盘文件系统上运行。

为了将SVN应用于数据库对象,必须将它们复制到本地磁盘文件系统中,并且必须将对本地磁盘文件系统的更改复制到数据库中。

不同的使用方式

与每个开发人员维护私有工作副本的源代码不同,开发人员倾向于在网络上的某个服务器上的共享数据库上工作。虽然Visual Studio为数据库的按需安装项目本地副本提供了直接支持,但开发人员已避开此工具,因为没有方便可靠的方法来合并更改。

但是,一旦数据库结构的更改由CVS或SVN等复制合并版本控制系统管理,传播和合并将主要是自动的(条形冲突)和 没有任何理由共享数据库。

排除SCC作为选项

Microsoft SQL Management Studio支持对实现SCC规范的任何内容进行版本控制。微软只列出了VSS(blech),但谷歌发布了大量的选择。 然而,SCC就是关于锁定 - 双重发布。

在文件系统之间复制

整个问题现在转向文件系统之间的复制问题。 CodePlex包含VS2005 / SQL2005的实现,但它不适用于VS2008 / SQL2008。

此时我认为“我应该如何解决这个问题”的基础问题得到了令人满意的解决,尽管我不确定如何奖励积分。

感谢所有关心你的意见。

确实会出现一些具体问题,主要与如何编写各种类型的架构对象有关。

  • 如何以依赖顺序提取createalter脚本
    • 查看
    • 存储过程
    • 功能
    • 触发
    • 索引
    • 外键
  • 如何按依赖顺序提取表格填充脚本
  • 如何有效地检测架构的更改(在sys.objects没有触发器的情况下,有必要进行轮询;最好是快速且便宜)

检测更改

我注意到可以使用策略将操作绑定到模式中的更改。仍存在依赖性排序和如何编写表创建语句的问题

6 个答案:

答案 0 :(得分:4)

我们使用Red Gate将当前架构与存储在SVN中的脚本文件进行比较,以获得基线,版本控制等

但是,我们的主参考实际上是生产的恢复副本。这是我们的基线,应该对应SVN。将主脚本提交到SVN是部署过程的一部分,Red Gate非常有用:它只更改已更改对象的文件。

我们进一步分离了我们的工作脚本和发布脚本(仅限更改),因此我们始终在SVN中拥有主数据库和基线。我们只使用脚本进行开发。

数据库源代码控制很好,但实现起来很有挑战性,因为SQL Server对象的性质是:某些表中的行或3 ......

答案 1 :(得分:1)

在一个非常简单的层面上,您可以编写一个监视文件系统的Windows服务,并解析aprticuler目录中的文件并将它们应用于数据库。使用SQL Server代理(或只是触发器和xp_commandshell)的simillar mechinsim可以用来反向编写。

答案 2 :(得分:1)

在过去六个月左右的时间里,我一直在开发一个名为ShiftSchema的工具,我认为这个工具与您的问题相关。

ShiftSchema使用数据库触发器将SQL Server 2005和2008数据库对象与磁盘上适合存储在版本控制系统中的文件同步。它还监视文件系统的更改(当您从存储库更新并获取其他开发人员提交的架构更改时),并将这些更改推送到您的个人开发数据库中。

它确实支持同步数据,但该功能实际上是针对少量数据,例如查找表。

它还具有比较两个数据库(在RDBMS或磁盘上)和生成DDL脚本以同步它们的工具。

ShiftSchema旨在用于每个开发人员都有自己的个人开发数据库的开发环境中。

如果您有兴趣,我的个人资料中的网站链接指向ShiftSchema网站。

答案 3 :(得分:1)

Red Gate正在构建SQL源代码控制,与SSMS集成以提供对源代码控制的提交和检索(在后台我们将数据库对象链接到源代码管理中保存的相应创建SQL文件)。虽然我们建议每个开发人员使用他们自己的数据库开发副本,但我们计划支持共享的模型,尽管这样做有一个缺点,即任何开发人员都可以随时为每个人破坏数据库。

我们希望在2010年上半年发布该工具。如果您想了解更多信息或注册我们的早期访问计划,请访问以下链接:

http://www.red-gate.com/products/SQL_Source_Control/index.htm

亲切的问候,

Red Gate Software产品经理David Atkinson

答案 4 :(得分:0)

w.r.t其他用户直接进入SQL服务器的更改: 我不知道这对你有多实用,但是通过SQL脚本进行所有更改可能是一个好主意,而不是单独地直接在服务器上进行。这些SQL脚本可以编号并放置在您选择的源代码控制中。为了更好地控制已部署的更改,您可以将everychange脚本与可在需要时使用的回滚脚本配对。

您当然需要教育用户,设置一些控件等,并调整部署过程,以便只有批准的更改才能通过脚本流向数据库环境。只是一个想法。

答案 5 :(得分:0)

您是否一定需要跟踪对对象或最后一个对象所做的每一次更改?我们在C#中编写了一个针对TFS的解决方案,因为我们有数据库中所有SQL对象的基线,然后使用Microsoft.SqlServer.Management.Smo中的方法,我们只是通过每个数据库对象并比较'工作集'到服务器版本。我们在晚上运行它作为我们晚上处理的一部分,通过9个数据库的整个服务器大约需要15分钟。我们发现它工作得很好,不涉及对SQL服务器/数据库的任何直接修改,它适用于SQL 2005/2008。它生成一个报告,邮寄给我们的数据库管理员,让他们知道哪些对象已经改变,然后允许他们通过TFS,看看有什么。

我最初是从这里开始的; http://odetocode.com/blogs/scott/archive/2008/02/02/versioning-databases-change-scripts.aspx

但发现我所寻找的并不是将更改推送到服务器而只是知道更改的方法。博客链接有一些不错的建议,希望可能会有所帮助。

问候。