问题标签 [database-versioning]

在工作中，我们有 4 个人一起在几个不同的项目上工作。对于每个项目，我们每个人都有一个我们正在处理的本地副本，然后有一个开发、登台和实时部署，以及我们拥有的任何分支（我们使用颠覆）。我们的数据库是 MySQL。

所以我的问题是，什么是管理对每个部署（以及开发人员的本地副本）进行了哪些数据库修订的好方法。现在，每个更改都会进入一个文本文件，该文件的名称带有时间戳，并放入项目下的文件夹中。老实说，这不是很好。我需要一个解决方案来帮助跟踪在哪里应用了什么。

我需要将版本放到 SQL Server 2005 数据库中，并从 .NET 应用程序中访问这些版本。我在想的是在数据库上使用名称为“版本”的扩展属性，当然该值将是数据库的版本。然后我可以使用 SQL 来解决这个问题。我的问题是这听起来像是一个好计划还是有更好的方法将版本添加到 SQL Server 数据库？

假设我无法使用表格来保存元数据。

我们目前正在巩固数据库变更管理流程。我们在 RedHat 5 上运行 MySql 5。我选择 LiquiBase 作为工具，因为它是开源的，并且允许我们稍后在需要时扩展它的功能。它似乎也是少数仍然活跃的免费项目之一。这里有人有使用 LiquiBase 或其他 Db 版本控制工具的经验吗？

公司背景：我们是一家提供 7/24 托管应用程序的 SaaS 公司。有几十个实例运行同一数据库的不同版本，我们需要一种方法来管理部署过程，因为它开始失控。数据库有数百个表，我们通常每 3 个月发布一次。

去年阅读和使用 Rails 时，给我留下最深刻印象的工具之一是 Rake。一个数据库版本控制系统，可以将所有开发数据库的相同内容直接集成到构建中......这样的事情会让生活变得更加轻松（和更安全）！

但是，我无法弄清楚的一件事是：当您实际上无法访问生产服务器时，如何将这些更改移动到生产服务器？我们在全国有多个服务器，通过安装包安装/升级应用程序。

注意：这个问题更多的是关于策略而不是 Rails/Rake 特定技术。我们不使用rails，我们使用.Net。但如果我能弄清楚这个发布场景，似乎有几个工具Migratordotnet可以让我们做类似的事情。

我已经到了意识到我必须开始对我的数据库模式和更改进行版本控制的地步。因此，我阅读了关于该主题的现有帖子，但我不确定如何继续。

我基本上是一家单人公司，不久前我什至没有对我的代码使用版本控制。我在 Windows 环境中，使用 Aptana (IDE) 和 SVN (with Tortoise)。我从事 PHP/mysql 项目。

什么是对我的数据库模式进行版本控制的有效且足够（没有矫枉过正）的方法？

在某些项目中，我确实有一两个自由职业者，但我预计不会发生很多分支和合并。所以基本上我想跟踪我的代码修订的并发模式。

[编辑]临时解决方案：目前我决定只要我要提交一个标签（稳定版本），我就只做一个模式转储加上一个带有必要的初始数据的转储。在现阶段，这对我来说似乎已经足够了。[/edit]

[edit2]plus 我现在还使用了第三个名为 increments.sql 的文件，我将所有更改与日期等放在其中，以便在一个文件中轻松跟踪更改历史记录。我不时将更改集成到其他两个文件中并清空 increments.sql[/edit]

我有一个使用非常大的数据库（超过 5 GB）的 Web 应用程序项目。数据库中的数据按项目分区。每个项目大约需要 1 GB，它是应用程序工作的最小集合（我们进行了一些数学计算，这些计算分布在这个数据集上，并且不能删除数据集的一部分）。

作为日常构建的一部分，我们还将我们的应用程序部署到测试环境中。为此，构建器运行自定义数据库更新实用程序，将当前数据库更新到适当的版本。但是我们还要求保留所有每日构建，以便 QA 团队可以“及时返回”并比较不同构建的计算结果。尽管我们尝试拥有向后兼容的数据模式，但有时它非常具有挑战性和耗时。所以，因此问题：

如果您需要保持以前的每日构建并运行，并且需要在进行日常构建的同时管理大型数据库，您会使用哪种数据库版本控制方法？

我们在前端使用 SQL Server 2005 和 ColdFusion 以及一些 Java，如果它有什么不同的话。

如何使用 VSS 管理 SQL 对象？

我可以将 SourceSafe / VSS 与 SQL Server 2005 集成吗？

我想在我的 SQL 模式中进行版本控制。

在 SO 播客第 54 集中， Jeff 谈到了使用 Visual Studio 将所有数据库对象保存到单个文件中。这听起来就像我的团队需要更好地在 TFS 中实现数据库模式更改，我告诉了我的领导。他认为这样做是个好主意。

不幸的是，到目前为止，我还没有让这对我有用。我的问题之一是我的本地机器上没有安装 SQL Server（部门策略）。我显然做错了什么。

有人可以给我一个步骤的概要或提供一个像样的链接吗？

谢谢！

下午好，

我目前处于一个用 .Net 编写并使用实体框架进行数据持久性/存储的新项目的早期阶段。所需的功能之一是能够“版本”某些模型类型。例如，一个模型是一个“需求”，它将有 n 个“需求版本”，基本上有一种方法可以回到那个特定“需求”实例的历史/生命周期。唯一必须在所有修订中保持静态的是它的“ID”，其他所有内容在需求的整个生命周期中都是绝对可变的。

现在的问题是，我是否应该“简单地”在 Requirement >> RequirementVersion 之间创建 1:n 关系？其他功能需要是完全恢复旧状态成为当前/最新状态的可能性，必须有能力拥有次要和主要版本（更改）等，最后但并非最不重要的是能够创建一个“基线”跨越具有最新版本的需求集合，以便稍后返回到该特定基线并显示所有包含的 RequirementVersions？

这必须扩展到几百万条需求记录，每个需求记录都有几千个修订版..这就是我特别问的原因..简单的 1:n 关系的缩放方面等。

有没有人做过类似的事情，也许还有一些关于版本控制/基线等的建议/最佳实践等？

干杯并感谢，-Jörg

以下是否是实现版本控制的可行策略（使用“示例”作为示例文档类型）：

拥有一份原始文档，其中类型字段名为 example_original。

文档的后续更改都以 example_change 类型和 example_original 文档的 id 作为键。更改还将带有时间戳。

保留一个类型为 example_current 的文档，该文档是 example_original 的结果，所有 example_change “已应用”。一个新的 example_change 文档将自动应用于该文档。

查找特定版本将包括检索 example_original 文档并应用所需的更改（主要是到某个时间戳，但也可能是许多更改）。

我应该提一下，我的用例将涉及对原始用例的有限数量的更改。大多数更新将包含新的原始文档。虽然这是我当前的用例，但如果涉及到许多更改，我也会对可能导致的问题感兴趣。

您认为这种方法有哪些优点和缺点？