sql - 如何持续交付基于 SQL 的应用程序？

Question

我希望将持续交付概念应用于我们正在构建的 Web 应用程序，并想知道是否有任何解决方案可以保护数据库免受意外错误提交。例如，擦除整个表而不是单个记录的错误。

根据持续交付理论，如何限制这个问题的影响，其中应用程序逐渐部署在基础设施的各个部分上？

有任何想法吗？

Answer 1

您担心的是数据库中发生了不良数据。解决方案是使用所有事务的完整日志记录，以便您可以退出您想要的事务。这通常用于完整备份/增量备份/完整日志记录的上下文中。

例如，假设您有完整的日志记录，SQL Server 允许您恢复到某个时间点 (http://msdn.microsoft.com/en-us/library/ms190982(v=sql.105).aspx)。

如果您正在创建和删除表，就日志所需的空间而言，这可能是一个昂贵的解决方案。但是，它可能会满足您的开发需求。

您可能会发现，对于这样的应用程序来说，完整日志记录太昂贵了。在这种情况下，您可能希望进行定期备份（每天？每小时？）并保留这些备份。为此，我发现 LightSpeed 是一款用于快速高效备份的好产品。

Answer 2

首先，你不能仅仅通过查看什么是糟糕的 SQL 语句来判断。您可能想要删除表的全部内容。因此，物理上不可能拥有检测意图的自动化工具。

因此，为了保护您的数据库，首先要确保您处于完全恢复（不是简单）模式，并且每晚进行一次完全备份，并且每 15 分钟左右进行一次事务日志备份。现在，无论过程中断多么严重，您都不会丢失太多信息。您的 dbas 应经过培训，以便能够及时恢复到某个时间点。如果您没有任何 dbas，我建议您可以做的最好的事情来保护您的数据是雇用一些。这在任何重要的数据库环境中都是不可协商的，如果您的数据对业务至关重要，那么没有训练有素、经验丰富的 dbas 是非常危险的。

接下来，您需要像对待任何其他代码一样对待 SQL，它应该在脚本的源代码控制中。如果您非常担心意外删除，请编写删除脚本以将所有删除复制到临时表并每周左右删除一次临时表的内容。在代码审查中强制执行此约定。或者更好的是设置一个贯穿触发器的审计流程。审核完所有记录后，无需恢复数据库即可轻松恢复 150 次意外删除。我永远不会考虑在没有审核的情况下拥有任何企业应用程序。

所有 SQL 脚本无一例外都应该像其他代码一样进行代码审查。所有 SQL 脚本都应在 QA 上进行测试并通过，然后再进行生产。这将大大减少出错的可能性。任何开发人员都不应该拥有生产的写入权限，只有 dbas 应该拥有。因此，应该编写每个脚本，以便可以运行，而不是一次运行一个块，您可能会不小心忘记突出显示 where 子句。培训您的开发人员在脚本中正确使用事务。

Answer 3

通常采用的策略之一是记录增量 sql 语句而不是集体模式生成，以便您可以在更精细的级别控制更改：

ex: 
change 1:
UP:
Add column
DOWN:
Remove column

change 2:
UP:
Add trigger
DOWN:
Remove trigger

一旦像这样增量捕获更改，您就可以拥有一个简单但高效的脚本来从任何版本升级（UP）到任何版本，而不必担心发生的更改。当更改 # 链接到 build 时，它变得更加有效。当您部署构建时，数据库也会自动升级（UP）或降级（DOWN）到该特定构建。

我们在 CloudMunch 有一个管道应用程序可以做到这一点。