如何将数据集与应用程序一起管理？
应用程序的代码和配置文件保存在代码库中。但有时，作为项目的一部分，我也有一些数据（在某些情况下可能大于100MB，大于1GB）存储在数据库中。 Git在处理代码及其更改方面做得很好，但开发团队如何轻松共享数据？如何将数据集与应用程序一起管理？
它并不真正适合在代码版本控制系统，因为它主要是大型的二进制文件，并会作出获取更新的噩梦。但它必须与存储库同步，因为一些代码修订版会更改模式（即迁移）。
你如何处理这种情况？
我们通常使用数据库同步或复制架构。
每个开发者都有数据库的2个副本，一个用于工作，另一个只是为了保持同步版本。
当代码是同步的，脚本同步数据库太大（相对于“死”开发商的副本中央DB）。之后，每个开发人员更新他自己的工作副本。有时开发人员需要保留一些他/她的数据，因此这些第二次更新并不总是由标准脚本驱动。
是一样强大的复制模式....有时（取决于DB），并不代表好消息。
在我看来，你的数据库有很多与二进制库相关的相似之处：这是大的（当然，不是一个合理的代码库大得多！），二进制，并有自己的版本，它必须对应于各种版本的代码库。
考虑到这一点，为什么不依赖管理器（例如Apache Ivy）与构建过程集成，并让它管理您的数据库？这看起来就像是一个依赖管理器的构建任务。除非您可以将数据序列化为可变量格式（XML/XML格式），否则关于数据/下载的庞大规模，我认为没有任何神奇的项目符号（缺少一些严重的文档预加载基础结构）你提到的JSON/SQL）。
第二种方法（可能与依赖管理不兼容）：如果代码的具体情况允许，则可以保留第二个文件，该文件是手动比较，可以将基本数据库（版本0）数据库直到版本X.每个开发人员都需要保持一个干净的版本0.一个拉（具有更改的数据库的版本）将包括：拉差异文件，将版本0复制到工作数据库，应用差异文件。请注意，应用diff文件可能需要一段时间才能处理较大的数据库，因此您可能无法像在第一次看到时那样节省直接下载的时间。
感谢Greg，您的第一个解决方案听起来很酷。我会检查出来的。 你的第二个解决方案 - 数据库数据迁移 - 在理论上是非常好的，但我无法在现实生活中使用它（我正在使用它，这就是我的问题的原因）。这需要比评论更长的时间来解释原因。我应该写一篇关于它的博客文章:) – 2010-08-31 08:59:37
@Ofri，当然有道理。对于一般情况来说，这仍然可能有用 - 这是我发现自己在类似情况下最经常做的事情。不幸的是，我认为会有一些大的下载并且没有办法解决这个问题......我们已经通过了拨号上网的好事。 :-) – Greg 2010-08-31 14:07:55
我认为关键部分是“哪些必须对应于您的代码库的各种版本。” 。我们发现并非所有开发人员都同意这一点，因为他们的单元测试数据（例如）演化速度太快......比他们预期的代码提交速度快得多。只是我2C – 2010-08-31 23:24:26
DataGrove是一个新产品，让你的数据库版本控制。我们允许您在任何时间点存储整个数据库（模式和数据），标记，恢复和共享数据库。
这听起来像是你在找什么。
我们目前正在对功能，让混帐样（推挽）行为，因此开发人员可以跨机器共享他们的仓库，所以，当我需要它，我可以加载最新版本的数据库。
通过数据你的意思是在一个数据库或其他地方的一些平面文件（如电影或MP3文件的集合例如）数据？ – slebetman 2010-08-01 19:19:16
在我的情况下，它的数据库。我可以将它导出到一些XML/JSON/SQL文件，但这将是一个非常大的文件。 – 2010-08-02 03:43:48