Windows工作流SQL持久体系结构

Question

我喜欢WF的想法，并希望将长时间运行的工作流持久化到SQL数据库。为此，持久性数据库的SQL级别的适当体系结构是什么？如果持久性表存在于项目的数据库中，或者是持久性数据表项目agnositc并且只有一个持久性数据库被创建，那么就是一个la SSRS的数据库。多个应用程序能否使用一个持久性数据库

Answer 1

一般来说，我宁愿将持久性数据和应用程序数据放在一个数据库中。反对分裂它们的主要原因是，只要您执行任何慢得多的事务数据库工作，就立即开始创建分布式事务。

我从来没有将不同的持久性数据库合并为一个。实际上，每个应用程序的WorkflowRuntime都将进行不同的配置，因此您的工作流程不仅可以选择要运行的任何主机，还可以绑定到专门配置的工作流程类型。一旦开始使用DelayActivities并且它们到期，您无法控制哪个运行时将尝试将工作流加载回内存。使用一个持久性数据库与多个SAME工作流类型的实例进行负载平衡是可能的，但有点挑战。实际上，在单个应用程序中使用不同配置的WorkflowRuntimes的多个持久性数据库更为常见，这种情况恰恰相反。

Answer 2

SQL持久性数据库不耦合到您的应用程序或项目。每个工作流程都是完全原子的，并且由GUID唯一标识。因此应该可以在多个应用程序间共享一个通用的工作流持久性DB。

但是，确实有维护多个持久性DB的情况，每个应用程序都有一个DB。如果多个应用程序的操作依赖于工作流程，则您不希望通过共享一个常见的持久性数据库来创建潜在的单点故障。

从性能和可伸缩性的角度来看，分离持久性数据库也是有意义的。否则，您可以在沉重的应用程序影响其他应用程序的性能时创建瓶颈。您也可以决定将一个或多个应用程序的持久性DB更轻松地移到不同的服务器。