모범 사례:항목의 워크플로 상태를 데이터베이스에 저장하시겠습니까?

Question

데이터베이스에서 작업을 처리하기 위해 복잡한 워크플로 상태를 저장하는 방법에 관한 모범 사례에 대한 질문이 있습니다.나는 온라인에서 아무 소용이 없었기 때문에 커뮤니티에 무엇이 가장 좋다고 생각하는지 물어봐야겠다고 생각했습니다.

이 질문은 이전 질문에서 제공한 것과 동일한 "BoxItem" 예제에서 나왔습니다.이 "BoxItem"은 다양한 작업이 수행될 때 내 시스템에서 추적되고 있습니다.작업은 며칠에 걸쳐 인간 상호 작용을 통해 수행될 수 있으므로 BoxItem의 상태가 지속되어야 합니다.작업을 수행한 사람(해당되는 경우)과 작업이 완료된 시기도 추적해야 합니다.

처음에는 수행해야 하는 모든 인간 대화형 작업에 대해 "BoxItems" 테이블에 세 개의 필드를 추가하여 이에 접근했습니다.

~이다작업 이름완벽한

날짜작업 이름완벽한

사용자작업 이름완벽한

이는 작업 흐름이 단순할 때 작동했습니다.하지만 이제는 복잡한 프로세스로 성장했습니다(흐름에서 인간 상호 작용이 10개 이상 가능...).그 중 약 절반은 선택 사항이며 BoxItem에 대해 수행될 수도 있고 수행되지 않을 수도 있습니다. 이로 인해 "Do"를 추가하기 시작했습니다.작업 이름" 필드도 포함), 단순한 테이블이어야 했던 것이 이제 이 상태 정보를 유지하는 데 전적으로 사용되는 40개 정도의 필드가 있다는 것을 발견했습니다.

혹시 더 좋은 방법은 없는지 문의드립니다...하지만 나는 헤매고 있어요.

내 첫 번째 생각은 주어진 상자에서 수행할 수 있는 작업을 정의하는 일반적인 "BoxItemTasks" 테이블을 만드는 것이었지만 여전히 날짜 및 사용자 정보를 개별적으로 저장해야 하므로 실제로 도움이 되지 않았습니다.

두 번째 생각은 아마도 문제가 되지 않을 것이며 이 테이블에 상태 유지에 사용되는 필드가 40개 이상 있어도 걱정할 필요가 없다는 것이었습니다.어쩌면 내가 편집증적인 것일 수도 있습니다.하지만 유지해야 할 정보가 너무 많은 것 같습니다.

어쨌든, 나는 세 번째 옵션이 무엇인지, 또는 위의 두 가지 옵션 중 하나가 실제로 합리적인지에 대해 고민하고 있습니다.이 워크플로는 앞으로 훨씬 더 복잡해질 가능성이 있으며, 새로운 작업마다 추적을 지원하기 위해 3~4개의 필드를 추가해야 합니다.통제 불능 상태에 빠지는 것 같은 느낌이 듭니다.

이 상황에서 당신은 어떻게 하시겠습니까?

이는 ORM 없이 구축된 기존 시스템의 유지 관리이므로 이를 ORM에 맡겨 처리할 수는 없다는 점에 유의해야 합니다.

편집하다:

케브, 이런 일을 하는 것에 대해 이야기하고 있나요?

상자항목

(PK) BoxItemID

(기타 관련 없는 내용)

BoxItemActions

(PK) BoxItemID

(PK) BoxItemTaskID

완성 됐습니다

완료 날짜

사용자 완료

BoxItem작업

(PK) 태스크 유형

설명(필요한 경우)

흠...그게 효과가 있을 텐데...어떤 항목이 어떤 상태에 있는지 확인하기 위해 현재 SQL 쿼리를 수행하는 방법을 변경할 필요가 있음을 나타내지만 장기적으로 이와 같은 것이 더 잘 작동할 것처럼 보입니다(직렬화 아이디어와 같은 근본적인 디자인 변경을 하지 않고도). 나타냅니다...하지만 시간이 된다면 그렇게 하고 싶다고 생각합니다.)

그래서 이것이 당신이 Kin에 대해 언급한 것입니까, 아니면 제가 그 말을 하는 것입니까?

편집하다:아, 현재 상태를 판단하기 위한 "마지막 조치"에 대한 귀하의 생각도 알겠습니다...좋아요!내 생각엔 그게 나한테는 효과가 있을 것 같아...(어떤 시점에서는 작업이 동시에 발생하기 때문에) 약간 변경해야 할 수도 있지만 아이디어는 좋은 것 같습니다!

최종 편집:요약하자면, 다른 사람이 나중에 같은 질문으로 이것을 찾아본다면...시스템에 쿼리 가능한 일부 인터페이스(예:내가 작업 중인 임시 시스템처럼 데이터베이스 자체를 직접 호출하지는 않지만) 데이터베이스가 없으면 추가 테이블 아이디어가 잘 작동할 것 같습니다!귀하의 답변에 감사드립니다!

Answer 1

올바르게 이해했다면 BoxItemTasks 테이블(열거형 테이블만 해당)을 추가한 다음 BoxItems 및 BoxItemTasks에 대한 외래 키가 있는 BoxItemActions 테이블을 추가하여 작업 유형을 설명합니다.특정 상자 항목에 대해 특정 작업을 한 번만 수행할 수 있도록 하려면 (항목 + 작업) 열 쌍을 BoxItemActions의 기본 키로 설정하면 됩니다.

(저보다 훨씬 잘 설명하셨고, 제 말을 정확하게 해석해주셔서 감사합니다.당신이 쓴 것은 내가 상상했던 것과 정확히 같습니다.)

현재 상태를 확인하려면 단일 열 BoxItems.LastAction을 업데이트하는 BoxItemActions에 대한 트리거를 작성할 수 있습니다.동시 작업의 경우 트리거에는 최신 작업이 필요한 작업을 결정하는 특별한 경우가 있을 수 있습니다.

Answer 2

이전 답변에서 제안했듯이 테이블을 여러 개로 나눌 것입니다.

작업 흐름에서 수행해야 하는 작업 목록이 포함된 BoxItemActions는 BoxItem이 생성될 때마다 생성됩니다.이 테이블에서는 각 작업이 완료된 자세한 날짜\회\사용자를 추적할 수 있습니다.

이러한 유형의 응용 프로그램을 사용하면 Box가 다음에 어디로 갈지 아는 것이 매우 까다로울 수 있으므로 Box의 나머지 단계에 대한 '지도'가 있으면 매우 유용할 것입니다.또한 이 테이블은 상자당 수백 개의 행을 엄청나게 그룹화할 수 있으며 여전히 쿼리하기가 매우 쉽습니다.

또한 쉽게 변경할 수 있는 '다른 경로'를 갖는 것도 가능합니다.작업 흐름을 통한 '경로'의 마스터 데이터 테이블은 각 상자가 생성될 때 사용자가 상자가 따를 '경로'를 선택해야 하는 하나의 솔루션입니다.또는 사용자가 상자를 만들 때 이 특정 상자에 필요한 작업을 선택하도록 설정할 수도 있습니다.우리의 비즈니스 문제에 따라 다릅니다.

Answer 3

직렬화와 데이터베이스 모델의 하이브리드는 어떻습니까?이름, 프로세스 순서, 선택 사항인지 여부에 대한 조건 등을 자세히 설명하는 속성과 요소가 있는 각 단계의 노드를 포함하는 마스터 워크플로 문서 역할을 하는 XML 문서를 만듭니다.가장 중요한 것은 각 단계 노드가 고유한 단계 ID를 가질 수 있다는 것입니다.

그런 다음 데이터베이스에는 간단한 두 개의 테이블 구조가 있습니다.BoxItems 테이블은 기본 BoxItem 데이터를 저장합니다.그런 다음 답변으로 표시한 솔루션과 매우 유사한 BoxItemActions 테이블이 생성됩니다.

이는 대답으로 받아들여진 솔루션과 본질적으로 유사하지만 작업의 마스터 목록을 저장하는 BoxItemTasks 테이블 대신 실제 워크플로 정의에 더 많은 유연성을 허용하는 XML 문서를 사용합니다.

Answer 4

그만한 가치가 있기 때문에 BizTalk에서는 장기 실행 메시지 패턴(워크플로 등)을 데이터베이스에 대해 이진 직렬화하여 "디하이드레이션"합니다.

Answer 5

저는 Workflow 개체를 XML로 직렬화하고 ID 열을 사용하여 데이터베이스에 저장할 것이라고 생각합니다.보고하기가 더 어려울 수 있지만 귀하의 경우에는 효과가 있을 것 같습니다.

Answer 6

이러한 종류의 문제에 대해서는 다음과 같은 데이터베이스 스키마를 고려하십시오. http://www.databaseanswers.org/data_models/workflow/index.htm 이는 비즈니스 프로세스에서 일련의 이벤트를 모델링합니다.