我正在寻求将持续交付概念应用于我们正在构建的Web应用程序，并想知道是否有任何解决方案来保护数据库免于意外错误提交。例如，删除整个表而不是单个记录的错误。
如果应用程序逐渐部署在基础架构的各个部分上，那么这个问题的影响如何受到限制？
有什么想法吗？
答案 0 :(得分：1)
您担心的是数据库中发生的数据不正确。解决方案是使用所有事务的完整日志记录，以便您可以退出所需的事务。这通常用于完全备份/增量备份/完整日志记录的上下文中。
例如，SQL Server允许您恢复到某个时间点（http://msdn.microsoft.com/en-us/library/ms190982(v=sql.105).aspx），假设您有完整记录。如果要创建和删除表，就日志所需的空间而言，这可能是一种昂贵的解决方案。但是，它可能会满足您的开发需求。
您可能会发现完整日志记录对于此类应用程序而言过于昂贵。在这种情况下，您可能希望定期备份（每天？每小时？）并保持这些备份。为此，我发现LightSpeed是快速高效备份的好产品。
答案 1 :(得分：1)
首先，你不能只是看看什么是错误的SQL语句。您可能想要删除表的全部内容。因此，在物理上不可能拥有检测意图的自动化工具。
因此，为了保护您的数据库，首先要确保您处于完全恢复（非简单）模式，并且每晚进行一次完整备份，每15分钟左右进行一次事务日志备份。现在，无论过程多么糟糕，您都不会丢失太多信息。您的dbas应该经过培训，能够恢复到某个时间点。如果您没有任何dbas，我建议您可以采取的最佳措施来保护您的数据。这在任何非平凡的数据库环境中都是不可协商的，如果您的数据对业务至关重要，那么如果没有经过培训且经验丰富的dbas，那将是非常危险的。
接下来，您需要像对待任何其他代码一样处理SQL，它应该在脚本中的源代码控制中。如果您非常担心意外删除，请编写删除脚本以将所有删除复制到临时表，并每周删除一次临时表的内容。在代码评审中强制执行此约定。或者更好的是设置一个贯穿触发器的审核流程。审核完所有记录后，无需还原数据库就可以更轻松地恢复150次意外删除。如果没有审计，我绝不会考虑使用任何企业应用程序。
所有SQL脚本都应该像其他代码一样进行代码审查。所有SQL脚本都应该在QA上进行测试并在转移到porduction之前通过。这将大大降低错误的可能性。没有开发人员应该拥有生产的写权限，只有dbas应该拥有。因此，应该编写每个脚本以便可以运行，而不是在您可能意外忘记突出显示where子句的情况下运行一个块。培训您的开发人员也可以在脚本中正确使用事务。
答案 2 :(得分：0)
通常采用的策略之一是记录增量sql语句而不是集合模式生成，以便您可以在更细粒度的级别上控制更改：
ex:
change 1:
UP:
Add column
DOWN:
Remove column
change 2:
UP:
Add trigger
DOWN:
Remove trigger
一旦像这样逐步捕获更改，您就可以使用简单但高效的脚本从任何版本升级（UP）到任何版本，而无需担心发生的更改。当变更＃与构建相关联时，它变得更加有效。部署构建时，数据库也会自动升级（UP）或降级（DOWN）到特定构建。
我们有一个管道应用程序可以在CloudMunch上执行此操作。