我喜欢WF的想法，并且希望将长时间运行的工作流保存到SQL数据库中。为此，持久性数据库的SQL级别的适当架构是什么？如果持久性表存在于项目的数据库中，或者是持久性数据表项目agnositc，并且只创建一个持久性数据库，那么就是SSRS的数据库。多个应用程序可以使用一个持久性数据库吗？
答案 0 :(得分：4)
通常，我更喜欢将持久性数据和应用程序数据放在一个数据库中。反对拆分它们的主要原因是，一旦你执行任何事务数据库工作，你就会立即开始创建分布式事务。
我从未将不同的持久性数据库合并为一个。实际上，每个应用程序的WorkflowRuntime将以不同的方式进行配置，因此您的工作流程不能只选择要运行的任何主机，而是绑定到一个知道所有工作流程类型的专门配置的主机。一旦您开始使用DelayActivities并且它们过期，您无法控制哪个运行时将尝试将工作流加载回内存。尽管使用具有SAME工作流类型的多个实例的一个持久性数据库来实现负载平衡，但是有点挑战。实际上，在单个应用程序中为不同配置的WorkflowRuntimes提供多个持久性数据库更为常见，反之亦然。
答案 1 :(得分：1)
SQL Persistence数据库未与您的应用程序或项目耦合。每个工作流程都是完全原子的，由GUID唯一标识。因此，应该可以跨多个应用程序共享一个通用的工作流持久性DB。
但是，确实存在维护多个持久性DB的情况，每个应用程序一个。如果多个应用程序的操作依赖于工作流，则您不希望通过共享公共持久性DB来创建潜在的单点故障。
从性能和可伸缩性的角度来看，分离持久性DB也是有意义的。否则，您可以创建一个瓶颈，其中繁重的应用程序会影响其他应用程序的性能。您还可以决定将一个或多个应用程序的持久性DB更轻松地移动到其他服务器。