因此，虽然我原则上同意经常引用的文章"Get your database under version control"，但似乎没有人能解决大数据库的问题。我不是在谈论架构，而是数据。
此外，虽然我是像git和Mercurial这样的DVCS的大力支持者，但在处理大文件（而不仅仅是二进制文件）时，它们却不尽如人意。
这只是让我觉得这是配置管理问题，而不是版本控制问题。因此，我可以将SQL转储视为构建工件，将备份存储为工件的修订版并将其与项目中的清单配对，我可以对每个单一环境（分段，开发，生产，等等。）。我发现的一个缺点是Build Artifact Repositories（例如Artifactory和Nexus）似乎没有以存储效率的方式处理工件修订（例如差异备份）。
我的问题分为两部分：
A）这是一个完整的数据库备份 - 一个对生产环境足够健全的理智策略吗？这意味着，这个（或接近的）实际上是在现实世界中完成的吗？
B）以特定备份对生产应用程序的给定修订版具有可追溯性的方式管理（和使用！）数据库备份的最佳实践是什么？
答案 0 :(得分：0)
数据库架构更改是部署问题。项目的每个版本都应具有从先前版本更新数据库的代码。您的临时服务器应该备份，您可以在那里试用更改。