Best practice: memorizzazione di uno stato del flusso di lavoro di un elemento in un database?

Question

Ho una domanda sulle migliori pratiche per quanto riguarda l'approccio alla memorizzazione di stati complessi del flusso di lavoro per l'elaborazione delle attività in un database. Ho cercato online senza alcun risultato, quindi ho pensato di chiedere alla community cosa pensavano fosse meglio.

Questa domanda nasce dallo stesso " BoxItem " esempio che ho dato in una domanda precedente. Questo "BoxItem" viene monitorato nel mio sistema mentre vengono eseguite varie attività su di esso. L'attività può svolgersi per diversi giorni e con interazione umana, pertanto è necessario mantenere lo stato di BoxItem. Chi ha eseguito l'attività (se applicabile) e quando l'attività è stata eseguita deve essere monitorato.

Inizialmente, mi sono avvicinato a questo aggiungendo tre campi a " BoxItems " tabella per ogni attività umano-interattiva che doveva essere eseguita:

TaskName Completo

Data TaskName Completo

utente TaskName Completo

Funzionava quando il flusso di lavoro era semplice ... ma ora che è diventato un processo complesso (10 possibili interazioni umane nel flusso ... circa la metà delle quali sono opzionali e possono o meno essere eseguite per BoxItem, che mi ha portato ad aggiungere " Do TaskName " nonché campi per quelle attività opzionali), ho scoperto che quella che avrebbe dovuto essere una semplice tabella ora ha 40 o così campo dedicato interamente al mantenimento di questa informazione di stato.

Mi ritrovo a chiedere se non esiste un modo migliore per farlo ... ma sono in perdita.

Il mio primo pensiero è stato quello di creare un generico "BoxItemTasks" tabella che definisce le attività che possono essere eseguite su una determinata casella, ma avrei comunque bisogno di salvare la data e le informazioni dell'utente singolarmente, quindi non mi è stato di grande aiuto.

Il mio secondo pensiero è stato che forse non aveva importanza, e non dovrei preoccuparmi se questa tabella ha 40 o più campi dedicati al mantenimento dello stato ... e forse sono solo paranoico. Ma sembra che ci siano molte informazioni da conservare.

Comunque, sono in perdita per quanto riguarda quella che potrebbe essere una terza opzione, o se una delle due opzioni sopra è effettivamente ragionevole. Riesco a vedere questo flusso di lavoro potenzialmente diventare ancora più complesso in futuro, e per ogni nuova attività avrò bisogno di aggiungere 3-4 campi solo per supportare il monitoraggio di esso ... sembra che stia andando fuori controllo.

Cosa faresti in questa situazione?

Dovrei notare che si tratta della manutenzione di un sistema esistente, uno che è stato costruito senza un ORM, quindi non posso lasciarlo all'ORM per occuparmene.

EDIT:

Kev, stai parlando di fare qualcosa del genere:

BoxItems

(PK) BoxItemID

(Altre cose irrilevanti)

BoxItemActions

(PK) BoxItemID

(PK) BoxItemTaskID

IsCompleted

DateCompleted

UserCompleted

BoxItemTasks

(PK) TaskType

Descrizione (se necessario)

Hmm ... che funzionerebbe ... rappresenterebbe la necessità di cambiare il modo in cui mi sto avvicinando a fare query SQL per vedere quali elementi sono in quale stato, ma a lungo termine qualcosa del genere sembra che funzionerebbe meglio (senza dover apportare una modifica sostanziale al design come l'idea di serializzazione rappresenta ... anche se se avessi il tempo, mi piacerebbe farlo nel modo in cui penso.)

Quindi è questo ciò di cui stavi citando Kin, o me ne vado?

EDIT: Ah, vedo anche la tua idea con la "Ultima azione" per determinare lo stato attuale ... mi piace! Penso che potrebbe funzionare per me ... Potrei doverlo cambiare un po '(perché a un certo punto le attività si svolgono contemporaneamente), ma l'idea sembra buona!

MODIFICA FINALE: Quindi, in sintesi, se qualcun altro lo sta cercando in futuro con la stessa domanda ... sembra che l'approccio di serializzazione sarebbe utile se il tuo sistema ha le informazioni precaricate in qualche interfaccia in cui è interrogabile (cioè non chiamando direttamente il database stesso, come fa il sistema ad-hoc su cui sto lavorando), ma se non lo hai, l'idea delle tabelle aggiuntive sembra che dovrebbe funzionare bene! Grazie a tutti per le vostre risposte!

Answer 1

Se capisco correttamente, aggiungerei la tabella BoxItemTasks (solo una tabella di enumerazione, giusto?), quindi una tabella BoxItemActions con chiavi esterne a BoxItems e BoxItemTasks per il tipo di attività. Se vuoi farlo in modo che una determinata attività possa essere eseguita una sola volta su un particolare elemento della casella, fai in modo che la coppia di colonne (Articoli + Attività) sia la chiave primaria di BoxItemActions.

(L'hai presentato molto meglio di me, e complimenti per aver interpretato correttamente quello che stavo dicendo. Quello che hai scritto è esattamente quello che stavo immaginando.)

Per quanto riguarda la determinazione dello stato corrente, è possibile scrivere un trigger su BoxItemActions che aggiorna BoxItems.LastAction a colonna singola. Per le azioni simultanee, il tuo trigger potrebbe avere solo casi speciali per decidere quale azione richiede la recency.

Answer 2

Come suggerito dalla risposta precedente, spezzerei il tuo tavolo in diversi.

BoxItemActions, contenente un elenco di azioni che il flusso di lavoro deve attraversare, creato ogni volta che viene creato un BoxItem. In questa tabella è possibile tenere traccia delle date dettagliate \ volte \ utenti di quando ciascuna attività è stata completata.

Con questo tipo di applicazione, sapere dove andrà il Box successivo può diventare piuttosto complicato, quindi avere una 'Mappa' dei passaggi rimanenti per il Box si rivelerà molto utile. Inoltre, questa tabella può raggrupparsi come un matto, centinaia di righe per scatola, e sarà comunque molto facile interrogare.

Permette anche di avere "percorsi diversi" che possono essere facilmente modificati. Una tabella di dati master di "percorsi" attraverso il flusso di lavoro è una soluzione, in cui ogni casella viene creata, l'utente deve selezionare quale "percorso" seguirà la casella. Oppure è possibile impostare in modo che quando l'utente crea la casella, selezionano le attività necessarie per questa particolare casella. Dipende dal nostro problema commerciale.

Answer 3

Che ne dici di un ibrido della serializzazione e dei modelli di database. Avere un documento XML che funge da documento principale del flusso di lavoro, contenente un nodo per ogni passaggio con attributi ed elementi che descrivono in dettaglio il nome, l'ordine nel processo, le condizioni se è facoltativo o meno, ecc. Soprattutto, ogni nodo del passaggio può avere un ID passaggio univoco.

Quindi nel tuo database hai una semplice struttura a due tabelle. La tabella BoxItems memorizza i dati BoxItem di base. Quindi una tabella BoxItemActions è molto simile alla soluzione contrassegnata come risposta.

È essenzialmente simile alla soluzione accettata come risposta, ma invece di una tabella BoxItemTasks per memorizzare l'elenco principale delle attività, si utilizza un documento XML che consente una maggiore flessibilità per la definizione del flusso di lavoro effettivo.

Answer 4

Per quello che vale, in BizTalk essi "disidratano" modelli di messaggi di lunga durata (flussi di lavoro e simili) serializzandoli binariamente nel database.

Answer 5

Penso che vorrei serializzare l'oggetto Workflow su XML e archiviarlo nel database con una colonna ID. Potrebbe essere più difficile riferire, ma sembra che possa funzionare nel tuo caso.

Answer 6

Per questo tipo di problema, considera lo schema del database mostrato in http: // www .databaseanswers.org / data_models / workflow / index.htm che modella una serie di eventi in un processo aziendale.