情况
我正在开发一个使用 SQL Server 来存储数千条记录的 Web 应用程序。我们目前正在使用源代码控制软件来保存应用程序的每个版本。该应用程序有 2 个主要版本:
- 测试版(我们实际开发的那个)
- 现场版(目前在网站上的那个)
我们每个月左右发布一个新的“主要”Live 版本，但在此期间我们可能会发现当前 Live 版本上的许多小错误。为了修复这些错误，我们回到 Live 当前在我们的测试机器上运行的版本(我们使用共享数据库进行测试……)。重现错误，找到原因，修复它，然后我将补丁应用到有错误的版本，然后我们立即上线，并将错误修复合并到测试版本中。在每个“主要”版本之间的月份，我们可以发布很多小错误修复补丁。
问题
目前的问题是只有源代码在版本控制之下；数据库不受版本控制。这是一个问题的原因是，在开发下一个“主要”版本时，数据库中的许多内容可能会发生变化，与以前的版本不兼容。因此，即使我们可以回到以前版本的代码，数据库也不能做同样的事情，因此我们无法测试以前的版本，除非我们有当时的数据库备份。
显而易见的解决方案似乎是将数据库置于版本控制之下。虽然将数据库架构和静态数据置于版本控制之下并不是真正的问题(我想我会使用 Visual Studio Database Project )，但我很难了解如何处理用户输入的数据。
问题
我需要将用户输入的数据输入到我的表中才能测试应用程序，因此我该如何处理用户输入的数据？
- 如何使用以前版本的数据访问数据库 此时在数据库中吗？
- 我应该将用户输入的数据置于版本控制之下吗？例如，为我们发布的每个版本使用数据库的完整备份……
- 审计是保存用户输入数据更改历史记录的好解决方案吗？
- 是否值得为用户输入的数据操心，因为它只是一个测试版本？我们始终可以手动重新创建测试应用程序所需的所有数据，但这可能会花费大量时间来测试一个小错误。
最佳答案
根据我的经验，我建议结合使用数据库备份和数据库升级脚本。您应该为主要版本保留生产数据或类似生产数据的备份(根据契约(Contract)，您可能有义务清除或更改包含客户姓名、地址、银行帐号等的数据)。从那开始，您应该能够获得数据库的任何中间版本，因为您正在编写数据库升级脚本并将它们保存在源代码控制系统中(您目前正在这样做，对吗？)
出于实际原因，您应该至少拥有两个独立的 QA 环境:一个具有与您的生产环境相匹配的数据库架构和应用程序，另一个 - 与正在开发的版本相匹配。
虽然数据库备份很大，但您只需要保留几个最新的备份，除非您预计需要对已停用多年的版本进行一些事后错误分析。
关于sql - 数据库版本控制——如何回到以前的版本并保留数据？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/22866327/