数据库文件（脚本等）应该在源代码控制中吗？如果是这样，保留它并在那里更新的最佳方法是什么？

甚至需要数据库文件进行源代码控制，因为我们可以将其放在开发服务器上，每个人都可以使用它，并在需要时对其进行更改。但是，如果有人把它弄乱了，我们就无法取回它。

哪种方法最适合源代码控制数据库？

是。您应该能够从源代码管理（包括数据库）重建系统的任何部分（并且我还会讨论某些静态数据）。

假设您不想使用某个工具来执行此操作，那么建议您包含以下内容：

• 基本表结构的创建脚本，包括模式，用户，表，键，默认值等。
• 升级脚本（更改表结构或将数据从以前的架构迁移到新架构）
• 用于存储过程，索引，视图，触发器的创建脚本（您不必担心对其进行升级，因为您只需要覆盖正确的创建脚本中的内容即可）
• 数据创建脚本以使系统运行（单个用户，任何静态选择列表数据之类的东西）

所有脚本都应包括适当的drop语句并进行编写，以便它们可以以任何用户身份运行（因此，如果相关，请包括关联的架构/所有者前缀）。

更新/标记/分支的过程应与其余的源代码完全相同-如果您无法将数据库版本与应用程序版本相关联，那么这样做毫无意义。

顺便说一句，当您说人们可以更新测试服务器时，我希望您是指开发服务器。如果开发人员正在动态更新测试服务器，那么在制定需要发布的内容时，您将面临很多痛苦。

是。

保留并在那里更新的最佳方法是什么？

嗯 编写一个模式构建器脚本。进行更改后签入。在运行之前先检查一下。

很难确定您的要求。

编写正式的模式迁移脚本。测试后检查它们。在运行它们之前将其检出。

还有什么呢？

发生的事情是，模式更改变成了棘手的问题，因为模式是通过一系列未记录的更改有机地演变的。

这种有机的演变使模式迁移变得更加困难，因为没有所谓的“权威”资源。有两个略有不同的生产版本，一个临时版本，一个QA版本和八个开发版本。都略有不同。

如果只有一个权威的来源，那么架构迁移就是最后一个版本与该版本之间的差异。

是

数据库脚本（ddl，dml）是代码。 所有代码都应在版本控制系统中。

移居

• 使用数据库迁移

允许您在开发，质量检查和发行版中使用相同的数据库文件。

• 使用版本号发布到数据库

将发行版号存储在某个地方以供审核，许多版本号存储在db本身中。每个发行版都将包含迁移，这些迁移会将数据库升级到正确的版本。

有诸如liquibase之类的工具，旨在为数据库提供源代码控制。像许多公司一样，在常规的源代码控制工具中维护更改/更新脚本很麻烦，而且您不能总是从头开始重新部署数据库。

我们还尝试使用数据库比较工具（比较主数据库和客户数据库）来实现此目的的自动化，但这样做很有帮助，但是您不能百分百地信任此类工具，您当然也需要进行审核。

是

而且，您将需要分支机构。

我将Git用于分支：

• 按功能进行开发（就像我们对其余应用程序进行常规开发一样）

• 和一个用于生产服务器，以及因为使用的应用程序的客户创造的内容了。

这样，您就可以从源代码控制和分支中获得源代码和数据库（以及您拥有的任何其他文件）的好处。

我还没有发现一个适用于PostgreSQL的多合一系统，因此我不得不编写函数/脚本来在合并分支时正确地重新编制索引（例如，不应修改生产分支中的任何索引，因为客户依赖它们，而应该重新索引开发分支中与生产内容相交的索引+外键：它不适用于所有应用程序，但涵盖了我们应用程序的所有情况，因此足够好。

但是一般的想法是数据库内容是应用程序的重要组成部分，所有资源都应位于源代码管理中，是的，您也应该对数据库使用源代码管理。

对于Java，我们的团队使用Flyway，我们发现它非常易于使用且功能强大。

如果您使用的是Ruby，Rails会提供Migrations，这也是解决此问题的有效方法。

已经提到了Liquibase-这是一个很好的解决方案，但我发现它比Flyway之类的替代品更麻烦。

另外，RedGate软件提供了一种称为SQL Source Control的产品，该产品是为SQL Server设计的。我自己没有使用过它，但是我的一位同事说这很棒。

当开发数据库上没有版本控制或变更管理时，这是我已经见过很多次的问题了。程序员A对表，视图或proc进行更改。程序员B对同一事物进行了更改，并覆盖了程序员A所做的事情。或者，DBA将生产数据库还原到开发中并覆盖更改。我已经看到这种东西引起了很多悲伤，这很多次都不好笑。这仅在开发系统上。当登台/测试时，甚至生产服务器陷入困境时，事情可能会变得非常混乱。

数据库版本控制不必与常规代码版本控制相同即可生效。但是，某种变更控制和历史记录备份将防止许多问题。

可以将其视为“版本控制”，而不是“源代码控制”。这意味着您可以看到该特定脚本的全部历史记录。是否可以将数据库重建为当前形式将更多地取决于这些脚本以及用于创建它们的任何框架的实践。

对于我们的PHP / MySQL项目，我们一直使用（一次）名为Ladder的小工具。它旨在促进数据库随着时间的自然增长。项目的所有迁移都存储在修订/源/版本控制中，并与代码一起进行跟踪。

它支持添加/更改/删除列，运行查询，添加/删除索引，约束等，它会跟踪数据库所处的状态，并应用所有丢失的迁移。它还允许您通过指定需要进行的迁移来“退后一步”。（php ladder.php migrate 15）

哦，最新添加的是数据库差异。运行diff-save命令，从数据库中添加和删除一些列，然后运行其diff命令。您将看到基于数据库状态的自动生成的迁移代码。

DataGrove解决了此处提到的一些问题（例如，通过jfrankcarr）。

它跟踪对数据库的所有更改，并允许您将整个数据库状态的版本保存到存储库中。然后，它允许您产生同一个数据库的多个虚拟副本，因此每个开发人员或DBA可以拥有自己的单独副本（每个虚拟副本可以从不同版本产生）。这将确保没有人能覆盖别人的代码/更改。每个虚拟副本也都被跟踪到相同的存储库中，因此可以轻松共享和重新创建所有数据库状态。

我还想带来一个监视工具，它也可以用作数据版本控制工具。我正在谈论的工具是MONyog，实际上它是一个MySQL监视工具，但是只要稍加修改，我们就可以轻松地将其用作数据版本控制。

但是，在进一步介绍之前，我引用不建议将整个数据库都进行版本控制。跟踪特定数据集的更改是真正的杀手。

MONyog具有一项称为CSO（自定义SQL对象）的功能，可以监视特定数据集的更改。这里介绍添加CSO 。现在，在MONyog的监视器历史记录部分中，您可以获取一段时间内的更改。最好，它在html页面中提供可视报告。该报告将如下所示