Best Practices:Speichern einer workflow-Status eines Elements in einer Datenbank?

Question

Ich habe eine Frage zu best practices in Bezug auf, wie sollte man Vorgehen Speicherung komplexe workflow-Zustände für die Verarbeitung von Aufgaben in einer Datenbank.Ich habe mich online ohne Erfolg, so dass ich dachte, ich würde bitten die community, was Sie dachte, war am besten.

Diese Frage kommt aus der gleichen "BoxItem" Beispiel gab ich in einer vorherigen Frage.Diese "BoxItem" verfolgt wird, die in meinem system, wie verschiedene Aufgaben werden auf es.Die Aufgabe kann über mehrere Tage und mit menschlicher Interaktion, also den Zustand der BoxItem müssen beibehalten werden.Wer hat die Aufgabe, die (falls zutreffend), und wenn die Aufgabe erledigt wurde, muss auch verfolgt werden.

Auf den ersten, ich ging Sie dies, indem Sie drei Felder der "BoxItems" Tabelle für jedes Mensch-interaktive Aufgabe, die getan werden musste:

IstTaskNameKomplett

DatumTaskNameKomplett

BenutzerTaskNameKomplett

Dies funktioniert, wenn der workflow war einfach...aber jetzt, es hat sich zu einem komplexen Prozess (> 10 möglich menschliche Interaktionen in den Fluss...über die Hälfte davon sind optional, und kann oder kann nicht getan werden, für die BoxItem, was dazu führte mich Anfang hinzufügen "TunTaskName"Felder als auch für diejenigen, die optionalen Aufgaben), die ich gefunden habe, dass das, was sollte habe eine einfache Tabelle hat jetzt 40 oder so in den Bereich widmet sich voll und ganz auf die Beibehaltung dieses Status-Informationen.

Ich finde mich zu Fragen, ob es nicht einen besseren Weg, es zu tun...aber ich bin an einem Verlust.

Mein Erster Gedanke war es, eine generische "BoxItemTasks" Tabelle definiert die Aufgaben, die getan werden kann auf einem bestimmten Feld, aber ich würde noch brauchen, um zu retten das Datum und die information der Nutzer individuell, so dass es nicht wirklich helfen.

Mein zweiter Gedanke war, dass es vielleicht nicht egal, und ich soll nicht sorgen, wenn diese Tabelle hat 40 oder mehr Felder gewidmet Staat die Beibehaltung...und vielleicht bin ich nur paranoid.Aber es fühlt sich an wie eine Menge von Informationen zu behalten.

Anyways, ich bin an einem Verlust, wie weit, was eine Dritte option sein könnte, oder wenn sich einer der beiden oben beschriebenen Optionen ist wirklich vernünftig.Ich kann sehen, dass dieser workflow möglicherweise immer noch komplexer in der Zukunft, und für jede neue Aufgabe brauche ich noch hinzufügen, 3-4 Felder nur zur Unterstützung der Verfolgung von es...es fühlt sich an wie es ist außer Kontrolle geraten.

Was würden Sie in dieser situation tun?

Ich sollte beachten Sie, dass dies die Wartung eines bestehenden Systems, eine, die gebaut wurde, ohne ein ORM, also ich kann nicht einfach lassen Sie es bis zu dem ORM zu nehmen Pflege von es.

EDIT:

Kev, sprechen Sie über etwas wie dieses:

BoxItems

(PK) BoxItemID

(Andere irrelevant stuff)

BoxItemActions

(PK) BoxItemID

(PK) BoxItemTaskID

IsCompleted

DateCompleted

UserCompleted

BoxItemTasks

(PK) TaskType

Beschreibung (wenn auch notwendig)

Hmm...das würde die Arbeit...es würde stellen müssen, wie ich derzeit Ansatz tun, SQL-Abfragen, um zu sehen, welche Elemente in welchem Zustand, aber auf lange Sicht, so etwas wie dieses sieht aus wie es besser funktionieren würde (ohne dass eine grundlegende design ändern, wie die Serialisierung Idee stellt...obwohl, wenn ich die Zeit hätte, würde ich wie zu machen es, dass Weg, denke ich.).

So ist es das, was Sie bereits erwähnt Kin, oder bin ich aus auf es?

EDIT:Ah, ich sehe deine Idee mit der "Letzte Aktion" zu bestimmen, den aktuellen Zustand...Ich mag es!Ich denke, das könnte für mich funktionieren...Ich haben könnte, ändern Sie es ein wenig (denn irgendwann Aufgaben geschehen gleichzeitig), aber die Idee scheint wie ein guter!

EDIT-FINAL:Also in Summe, wenn jemand anderes suchen, ist dieses in der Zukunft mit der gleichen Frage...es klingt wie die Serialisierung Ansatz wäre nützlich, wenn Ihr system hat die Informationen, die pre-geladen in eine Schnittstelle, wo es queryable (d.h.nicht direkt aufrufen der Datenbank selbst, als ad-hoc-system, mit dem ich arbeite), aber wenn Sie das nicht haben, die zusätzliche Tabellen Idee scheint, wie es sollte gut funktionieren!Ich danke Ihnen allen für Ihre Antworten!

Answer 1

Wenn ich verstehen richtig, ich möchte hinzufügen, die BoxItemTasks Tabelle (nur eine Aufzählung-Tabelle, richtig?), dann BoxItemActions Tabelle mit Fremdschlüsseln zu BoxItems und BoxItemTasks für welche Art von Aufgabe es ist.Wenn Sie möchten, um es so zu machen, dass eine bestimmte Aufgabe kann nur ausgeführt werden, sobald Sie auf ein bestimmtes Feld Element, machen einfach das (Artikel + Aufgaben) paar Spalten, die Primärschlüssel der BoxItemActions.

(Sie legte es viel besser, als ich es Tat, und kudos für richtig interpretieren, was ich sagen wollte.Was du geschrieben hast, ist genau das, was ich Malte.)

Für die Ermittlung des aktuellen Zustands, Sie schreiben, könnte ein trigger für BoxItemActions, dass wird eine einzelne Spalte BoxItems.LastAction.Für gleichzeitige Handlungen, Ihre Auslöser konnte nur spezielle Fälle zu entscheiden, welche Aktion dauert Aktualität.

Answer 2

Als Antwort schlug vor, ich würde brechen, Ihre Tabelle in mehrere.

BoxItemActions, enthält eine Liste der Aktionen, die der work-flow braucht, um durch zu gehen, jedes mal erstellt, wenn eine BoxItem erstellt.In dieser Tabelle können Sie verfolgen, die detaillierte Daten \ times \ Benutzer, wenn jede Aufgabe abgeschlossen wurde.

Mit dieser Art der Anwendung, zu wissen, wo sich das Feld zum nächsten gehen kann ganz schön knifflig, so dass eine 'Landkarte' der übrigen Schritte für die Box wird sehr hilfreich sein.Wie gut, kann diese Tabelle Gruppe wie verrückt, Hunderte von Zeilen, die pro box, und es wird noch sehr einfach zu Abfrage.

Es macht auch es möglich zu haben "unterschiedlichen Pfade", die kann leicht geändert werden.Ein Stammdaten-Tabelle der "Pfade" durch die Arbeit Fluss ist einer Lösung, wo, wie jedes Feld erstellt wird, hat der Benutzer auswählen, welche 'Pfad' der box Folgen.Oder Sie könnte so eingerichtet, dass, wenn der Benutzer erstellt die box, die Sie wählen Aufgaben, die erforderlich sind für diese Besondere box.Hängt auf unsere business problem.

Answer 3

Wie wäre es mit einem hybrid-der Serialisierung und der Datenbank-Modelle.Ein XML-Dokument dient als master-workflow-Dokument enthält einen Knoten für jede Schritt mit Attributen und Elementen, die Details, die diese Namen, um in den Prozess, die Bedingungen für die Frage, ob es fakultativ ist oder nicht, etc.Am wichtigsten ist jeder Schritt Knoten kann ein eindeutiger Schritt-id.

Dann in Ihrer Datenbank haben Sie eine einfache zwei-Tabelle Struktur.Die BoxItems Tabelle speichert Ihre grundlegenden BoxItem Daten.Dann BoxItemActions Tabelle ähnlich wie in der Lösung, die Sie als "Antwort" gekennzeichnet.

Es ist im wesentlichen ähnlich zu der Lösung angenommen als Antwort, aber statt einer BoxItemTasks Tabelle zum speichern der master-Liste der Aufgaben, die Sie in einem XML-Dokument, das für mehr Flexibilität für die eigentlichen workflow-definition.

Answer 4

Für was es Wert ist, in BizTalk Sie "Austrocknen" long-running Nachricht Muster (workflows und dergleichen), die durch binäre Serialisierung auf die Datenbank.

Answer 5

Ich glaube, ich würde serialisieren Sie die Workflow-Objekt zu XML und speichern in der Datenbank mit einer ID-Spalte.Es kann schwieriger sein, zu berichten, aber es klingt wie es kann Arbeit in Ihrem Fall.

Answer 6

Für diese Art von problem, betrachten Sie das Datenbank-schema dargestellt http://www.databaseanswers.org/data_models/workflow/index.htm die Modelle eine Reihe von Veranstaltungen in ein busniess process.