如何与应用程序一起管理数据集？

Question

应用程序的代码和配置文件保存在代码存储库中。但有时，作为项目的一部分，我还有一些数据（在某些情况下可以> 100MB，> 1GB左右），它存储在数据库中。 Git在处理代码及其更改方面做得很好，但开发团队如何轻松共享数据？

它并不真正适合代码版本控制系统，因为它主要是大型二进制文件，并且会使拉动更新成为一场噩梦。但它必须与存储库同步，因为某些代码修订会更改架构（即迁移）。

你如何处理这种情况？

Answer 1

我们将数据和模式存储在xml中，并使用liquibase来处理模式和数据的更新。这里的优点是你可以对文件进行区分以查看正在发生的事情，它可以很好地与任何VCS一起使用，并且可以自动化它。

由于数据库的大小，这意味着一个相当大的“版本0”文件。但是，使用迁移策略之后，更新应该是可管理的，因为它们只是增量。您也许可以将现有的迁移一对一转换为liquibase，这可能比大爆炸方法更好。

如果你的增量非常大，你也可以利用@belisarius'策略，这样每个开发者都不必单独应用增量。

Answer 2

在我看来，你的数据库与二进制库依赖有很多相似之处：它很大（嗯，比合理的代码库大得多！），二进制，并且有自己的版本，必须对应于各种版本的你的代码库。

考虑到这一点，为什么不将依赖管理器（例如Apache Ivy）与您的构建过程集成并让它管理您的数据库？这似乎只是为依赖管理器构建的那种任务。

关于数据/下载的庞大规模，除非您可以将数据序列化为可扩展的格式（XML / JSON），否则我认为没有任何神奇的内容（缺少一些严肃的文档预加载基础结构） /你提到的SQL）。

第二种方法（可能与依赖项管理不兼容）：如果您的代码的细节允许它，您可以保留第二个文件，它是一个手动差异，可以采用基础（版本0）数据库并启动它对于版本X.每个开发人员都需要保持一个干净的版本0.拉（具有更改的DB的版本）将包括：拉差异文件，将版本0复制到工作数据库，应用差异文件。请注意，对于相当大的数据库应用diff文件可能需要一段时间，因此您可能无法在直接下载时节省尽可能多的时间。

Answer 3

我们通常使用数据库同步或复制架构。

每个开发人员都有2个数据库副本，一个用于工作，另一个用于保持同步版本。

当代码同步时，脚本也会同步数据库（中央数据库与“死”开发人员的副本）。之后，每个开发人员都会更新自己的工作副本有时开发人员需要保留他/她的一些数据，因此这些第二次更新并不总是由标准脚本驱动。

它与复制模式一样健壮....有时（取决于数据库）不代表好消息。

Answer 4

DataGrove是一款新产品，可为您提供数据库版本控制。我们允许您在任何时间点存储整个数据库（模式和数据），标记，恢复和共享数据库。

这听起来像你在找什么。

我们目前正致力于提供类似git（推拉）行为的功能，以便开发人员可以跨机器共享他们的存储库，因此我可以在需要时加载最新版本的数据库。