【问题标题】：Exposing SQL Server database objects as files in a file system将 SQL Server 数据库对象公开为文件系统中的文件
【发布时间】：2009-10-19 02:21:31
【问题描述】：

有多个文件系统

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

大多数关系数据库系统的数据库对象确实存在于文件系统中，因为有一个标识对象的文本名称，并且可以检索或至少使用该名称生成创建脚本。

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

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

不同的使用方式

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

但是，一旦对数据库结构的更改由 CVS 或 SVN 等复制合并版本控制系统管理，传播和合并将大部分是自动的（条形冲突）和不再有任何理由共享数据库。

排除 SCC 作为选项

Microsoft SQL Management Studio 支持对任何实现 SCC 规范的内容进行版本控制。微软只列出了 VSS (blech)，但谷歌揭示了过多的选项。然而，SCC 是关于锁定的 - 双盲。

文件系统间复制

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

在这一点上，我认为“我应该如何解决这个问题”的基本问题已得到令人满意的解决，尽管我不确定如何奖励积分。

感谢所有相关人员的意见。

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

如何按依赖顺序提取create 和alter 脚本
- 表格
- 查看
- 存储过程
- 功能
- 触发器
- 索引
- 外键
如何按依赖顺序提取表填充脚本
如何有效检测架构更改（在sys.objects 上没有触发器的情况下，需要轮询；最好快速且便宜）

检测变化

我注意到，可以使用策略将操作绑定到架构中的更改。仍然存在依赖顺序以及如何编写表创建语句脚本的问题

【问题讨论】：

这是一个非常有趣的想法。很抱歉我没有这方面的经验，但我很想看到答案/

标签： sql-server svn samba vfs

【解决方案1】：

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

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

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

数据库源代码控制是个好东西，但由于 SQL Server 对象的性质，实施起来具有挑战性：某些表中的一行或 3 行...

【讨论】：

我们也使用 Red Gate 和几乎相同的操作实践。我正在努力提高自动化水平。

【解决方案2】：

在一个非常简单的级别上，您可以编写一个 Windows 服务来监视文件系统并解析 aprticuler 目录中的文件并将它们应用于数据库。可以使用使用 SQL 服务器代理（或仅触发器和 xp_commandshell）的类似 mechinsim 来编写反向操作。

【讨论】：

您说的很对，捕获磁盘上文件夹的更改非常容易，一个小服务可以轻松地将更改推送到服务器。但是，您所说的这个 SQL Server 代理是什么？
我只是查了一下，据我所知，它有点像使用数据库的 MSMQ。我不明白这将如何让我拦截对基本上不是表数据的所有内容的更新。
你是在建议我在系统表上放置触发器吗？

【解决方案3】：

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

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

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

它还具有比较两个数据库（在 RDBMS 中或在磁盘上）并生成 DDL 脚本以同步它们的功能。

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

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

【讨论】：

这听起来很像我的想法。我确实会检查 [原文如此] 你的工作。

【解决方案4】：

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

我们希望在 2010 年上半年发布该工具。如果您想了解更多信息或注册我们的抢先体验计划，请访问以下链接：

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

亲切的问候，

Red Gate Software 产品经理 David Atkinson

【讨论】：

早期访问计划现已结束，SQL Source Control v1.0 现已发布。请下载它并让我们知道它是否符合您的要求。 red-gate.com/products/SQL_Source_Control/index.htm

【解决方案5】：

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

您当然需要对用户进行培训，设置一些控制措施等，并调整部署过程，以便只有经过批准的更改才能通过脚本流向数据库环境。不过只是一个想法。

【讨论】：

需要教育用户，这才是关键。即使他们听了，有时他们也会忘记。
完全明白你的意思。只是觉得你可能有比我更合作的观众 ;-) 不过祝你好运。

【解决方案6】：

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

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

但发现我正在寻找的不是将更改推送到服务器的方法，而是简单地了解更改。博客链接有一些不错的建议，希望对您有所帮助。

问候。

【讨论】：

所以本质上您是在对数据库结构的每日快照进行版本控制？
是的，它服务于我们的 SAS70 审核员，他们只需要知道更改的内容和时间，而不一定是在开发过程中更改了 20 次。我们的生产服务器上的部署非常零星，因此它提供了一种基本回滚整个更新或部分回滚的好方法，因为您拥有所有历史记录。