我正在做一个web应用程序,我需要为一些主要的更改做一个分支,事情是,这些更改需要更改数据库模式,所以我想把整个数据库放在git下。

我怎么做呢?是否有一个特定的文件夹,我可以保存在git存储库下?我怎么知道是哪个?我如何确定我放入了正确的文件夹?

我需要确定,因为这些更改是不向后兼容的;我可不能搞砸。

在我的例子中,数据库是PostgreSQL

编辑:

有人建议进行备份并将备份文件置于版本控制之下,而不是将数据库置于版本控制之下。说实话,我觉得这真的很难接受。

肯定有更好的办法。

更新:

好吧,没有更好的方法了,但我还是不太相信,所以我要稍微改变一下问题:

我想将整个数据库置于版本控制之下,我可以使用什么数据库引擎来将实际数据库置于版本控制之下,而不是转储?

sqlite是git友好的吗?

因为这只是开发环境,所以我可以选择任何我想要的数据库。

Edit2:

我真正想要的不是跟踪我的开发历史,而是能够从我的“新的根本性变化”分支切换到“当前稳定的分支”,并且能够用当前稳定的分支修复一些错误/问题等。这样,当我切换分支时,数据库就会自动地与我当前所在的分支兼容。 我不太关心实际数据。


当前回答

这个问题基本上已经回答了,但我想用一个小建议来补充X-Istence和Dana the Sane的回答。

如果您需要具有一定粒度的修订控制,比如每天,那么您可以使用rdiff-backup之类的工具将表和模式的文本转储与增量备份结合起来。这样做的好处是,不存储每日备份的快照,而只存储与前一天的差异。

这样你就有了修订控制的优势,也不会浪费太多的空间。

在任何情况下,直接在频繁更改的大平面文件上使用git都不是一个好的解决方案。如果数据库变得太大,git在管理文件时会出现一些问题。

其他回答

有一个伟大的项目叫做“教义下的移民”,就是为了这个目的而建立的。

它仍然处于alpha状态,是为php构建的。

http://docs.doctrine-project.org/projects/doctrine-migrations/en/latest/index.html

我认为X-Istence在正确的轨道上,但你可以对这一策略进行更多的改进。首先,使用:

$pg_dump --schema ... 

转储表、序列等,并将此文件置于版本控制之下。您将使用它来分离分支之间的兼容性更改。

接下来,对一组表执行数据转储,这些表包含应用程序操作所需的配置(可能应该跳过用户数据等),比如表单默认值和其他不可修改的数据。你可以有选择地使用:

$pg_dump --table=.. <or> --exclude-table=..

这是一个好主意,因为当数据库达到100Mb以上时,在进行完整的数据转储时,回购会变得非常笨拙。更好的办法是备份你测试应用所需的最小数据集。如果你的默认数据非常大,这仍然可能导致问题。

如果您确实需要在回购中放置完全备份,请考虑在源代码树之外的分支中进行备份。不过,一个引用了匹配的svn rev的外部备份系统可能是最好的。

另外,我建议在修改时使用文本格式转储而不是二进制格式转储(至少对于模式而言),因为这些格式转储更容易区分。

最后,如果还没有查看postgres备份文档,请查看一下。你评论备份“数据库”而不是转储的方式让我怀疑你是否在考虑基于文件系统的备份(注意事项请参阅第23.2节)。

以下是我在项目中尝试做的事情:

分离数据、模式和默认数据。

数据库配置存储在不受版本控制的配置文件中(.gitignore)

数据库默认值(用于设置新项目)是一个受版本控制的简单SQL文件。

对于数据库模式,在版本控制下创建数据库模式转储。

最常见的方法是使用包含SQL语句的更新脚本(ALTER Table..或更新)。你还需要在你的数据库中有一个地方来保存你的模式的当前版本)

看看其他大型开源数据库项目(piwik,或者你最喜欢的cms系统),它们都使用updatescripts (1.sql,2.sql,3.sh,4.php.5.sql)

但这是一项非常耗时的工作,您必须创建并测试更新脚本,还需要运行一个通用的更新脚本来比较版本并运行所有必要的更新脚本。

所以理论上(这就是我正在寻找的)你可以 在每次更改后转储数据库模式(手动,conjob, git钩子(可能在提交之前)) (只有在一些非常特殊的情况下才创建更新脚本)

之后,在您的普通updatescript中(对于特殊情况,运行正常的updatescript),然后比较模式(转储和当前数据库),然后自动生成必要的ALTER语句。已经有一些工具可以做到这一点,但还没有找到一个好的工具。

采用一个数据库转储,并对其进行版本控制。这样它就是一个平面文本文件。

我个人建议同时保留一个数据转储和一个模式转储。通过使用diff,可以相当容易地看到从一个修订到另一个修订的模式中发生了哪些变化。

如果您正在进行大的更改,那么您应该有一个用于进行新模式更改的辅助数据库,而不会触及旧数据库,因为正如您所说的,您正在进行一个分支。

没有原子性就无法做到这一点,如果不使用pg_dump或快照文件系统,就无法获得原子性。

我的postgres实例在zfs上,我偶尔会对它进行快照。它几乎是即时和一致的。