저는 WF에 대한 아이디어가 마음에 들며 장기 실행 워크 플로를 SQL 데이터베이스에 유지하려고합니다. 이를 위해, 지속성 데이터베이스의 SQL 레벨에서 적절한 아키텍처는 무엇입니까? 지속성 테이블이 프로젝트의 데이터베이스 내에 존재해야 하는가 아니면 Persistence 데이터 테이블 프로젝트이고 하나의 지속성 데이터베이스 만 생성되어야 하는가, 즉 SSRS의 데이터베이스. 여러 응용 프로그램이 하나의 지속성 데이터베이스를 사용할 수 있습니까?Windows Workflow SQL 지속성 아키텍처
일반적으로 나는 지속성 데이터와 응용 프로그램 데이터를 하나의 데이터베이스에 보관하는 것을 선호합니다. 이들을 분할하는 주된 이유는 훨씬 느린 트랜잭션 데이터베이스 작업을 수행하는 즉시 즉시 분산 트랜잭션 생성을 시작하기 때문입니다.
다른 지속성 데이터베이스를 하나로 결합하지 않습니다. 실제로 각 응용 프로그램의 WorkflowRuntime은 다르게 구성되므로 워크 플로는 실행할 호스트를 선택할 수 없으며 워크 플로 유형에 대해 모두 알고있는 특정 구성 워크 플로에 바인딩됩니다. 그리고 DelayActivities를 사용하기 시작하면 만료됩니다. 어떤 런타임이 워크 플로를 다시 메모리에로드 할 것인지 제어 할 수 없습니다. 로드 균형 조정을 위해 동일한 워크 플로 유형의 여러 인스턴스와 함께 하나의 지속성 데이터베이스를 사용하는 것이 가능하지만 약간의 어려움이 있습니다. 사실 다른 방식으로 구성된 단일 응용 프로그램에서 다르게 구성된 WorkflowRuntimes에 대해 여러 개의 지속성 데이터베이스를 갖는 것이 일반적입니다.
SQL 지속성 데이터베이스는 응용 프로그램이나 프로젝트에 연결되어 있지 않습니다. 각 워크 플로는 완전히 원자 적이며 GUID로 고유하게 식별됩니다. 따라서 여러 응용 프로그램에서 공통 워크 플로 지속성 DB를 공유 할 수 있어야합니다.
그러나 각 응용 프로그램마다 하나씩 여러 개의 지속성 데이터베이스를 유지 관리해야 할 경우가 있습니다. 여러 응용 프로그램의 작업이 워크 플로에 의존하게되면 일반적인 지속성 DB를 공유하여 잠재적 인 단일 지점 오류를 생성하지 않으려 고합니다.
성능 및 확장 성 관점에서 보면 지속성 데이터베이스를 구분하는 것이 좋습니다. 그렇지 않으면 무거운 응용 프로그램이 다른 응용 프로그램의 성능에 영향을 미치는 병 목을 만들 수 있습니다. 하나 이상의 응용 프로그램에 대한 지속성 DB를 다른 서버로보다 쉽게 이동하도록 결정할 수도 있습니다.
+1 좋은 지적 지연. – AnthonyWJones