我最近开始对我所有的项目 VB.NET 代码使用 Kiln 源代码控制，我不知道没有它我是如何管理的！
我一直在为我的所有存储过程、UDF 等寻找数据库源代码控制。但是，我发现数据库版本控制没有我的 Web 文件可用的那么多。
为什么数据库版本控制不像我的 Web 文件那么重要？当然，我的数据库中的所有编程都与我的代码隐藏和 .aspx 文件中的代码一样重要吗？
问问题
385 次
7 回答
6
版本控制数据库对象很重要！
但是，也许它不被认为是重要的，因为有些人将数据库仅仅视为帮助他们的工具？并且外部工具（通常）不受版本控制。
我发现很难管理的一件事是发布过程。现在我们正在使用连接到 svn 的 red gates 源代码控制。当发布的时候，我们对其余代码执行相同的操作：从一个分支合并到另一个分支。然后为了部署它，我们使用 sql compare 在合并的修订版和实际数据库之间创建一个差异脚本。除了一些小的怪癖和初学者错误之外，我认为这在没有停机时间（故意;））并且具有高速开发过程（大量发布）的环境中效果很好。
于 2011-07-22T10:00:41.110 回答
1
VCS 旨在存储文本版本。他们可以存储二进制文件，但效率较低。而且数据库状态本身不是文本，甚至不能直接存储为二进制文件。不过，您可以存储 SQL 代码。
一种解决方案是存储完整的 DB 转储（SQL 或二进制），另一种解决方案是存储将一个 DB 状态更改为下一个状态的 SQL 脚本序列。第二种方法可以在某些环境中实现自动化，称为迁移。如果您想要一个单独的特定 VCS 用于数据库，您可以认为迁移工具就是这样的 VCS。
还有一些工具可以比较两个 DB 状态并生成能够将第一个状态更改为第二个状态的差异。
于 2011-07-22T10:02:00.873 回答
1
我想这取决于您是否将数据库更改（如 wRAR 提到的架构更改、迁移）作为源代码存储库的一部分、以 sql 脚本的形式或通过使用其他工具的其他格式来管理，或者您是否考虑这一点作为数据库管理，并使用传统的备份/恢复方法来做到这一点。
以我目前的经验来看，虽然我不会认为数据库管理不那么重要，但与实际代码更改相比，它发生的频率确实很低。您的情况显然不同，但脚本文件和数据库工具的组合应该可以解决这个问题。
于 2011-07-22T10:02:47.993 回答
1
您可以在版本控制系统中维护您的数据库工件。版本控制系统用于工件的版本控制，工件可以是程序代码或数据库。我们对代码和数据库使用相同的 VC。
于 2011-07-22T09:44:32.167 回答
1
您可以使用 SQL 源代码控制轻松地将 SQL Server 连接到 Kiln - http://www.red-gate.com/products/sql-development/sql-source-control/
于 2011-07-22T14:24:10.253 回答
1
我不知道它是否或为什么不被认为是重要的，但这里有一个可能有帮助的链接：
于 2011-07-22T09:50:24.240 回答
1
这就是现实。
数据库版本控制——也就是说，DDL、DML，甚至是应用程序具有基本功能所需的必要参考数据的数据——与版本控制下的所有其他应用程序资产一样重要。 数据库永远不应处于任何特殊例外情况下，即认为其资产（对象和必要的参考数据）不受版本控制是可以接受的。 曾经。
那么他们为什么会这样呢？简单的。保持简单管理这些资产的工具链并不总是符合要求（在 SQL Server 的情况下，在 Visual Studio 2008 之前它没有随 Microsoft 的第一方工具一起提供），并且工具链因供应商而异- 以供应商为基础。当这些工具链有缺陷时，除非组织加紧弥补该缺陷，否则该缺陷仍然存在。这是技术债务，一些组织由于时间或（可悲的）技能而没有优先考虑它，因为不存在简化它的工具或需要将第三方工具集成到开发工作流程中。
最糟糕的是试图将旧项目置于版本控制之下，因为除了向企业出售价值之外，您还必须让所有人同时与您一起踢球和尖叫。我不会不同意业务可能存在更紧迫的直接需求，但是将数据库资产置于版本控制之下需要在该列表中的某个位置，即使它的优先级较低。
没有任何借口。在这方面，我与足够多的项目经理、数据架构师，甚至 CIO/CTO 进行了斗争——我什至强调让批评者对我正在从事的每个项目进行批评。 它需要完成，如果没有，则需要有一个企业同意的时间表。 那些反对它的人需要被枪杀，幸存者需要再次被枪杀。
于 2012-05-09T02:40:58.660 回答