Modellazione di entità relazionali per gli Stati delle domande di revisione

Question

Questo è qualcosa che mi ha fatto dubitare per un po ', quindi ho pensato che sarebbe una buona idea pubblicarlo qui per trovare alcune informazioni, è un problema / dubbio relativo alla modellazione di database relazionali

Ho il seguente problema:

Ho " domande " che deve trovarsi in uno "stato" specifico e tutti i cambi di stato devono essere controllati.

Ho trovato due soluzioni a questo, ma non riesco davvero a vedere la differenza tra loro, se ce ne sono ... cosa ne pensi.

Ecco l'immagine con entrambi i diagrammi.

Modifica

Opzione A: tabella "domande" non deve contenere state_id e Question_State non deve contenere " id " campo. Ci scusiamo per gli errori.

EDIT2 :

Grazie per tutti gli esempi e le intuizioni del mondo reale, ma questo era un problema accademico, non legato al mondo reale :).

Answer 1

Penso che l'essenza di ciò che stai chiedendo sia: se lo stato della domanda fosse basato su una tabella intermedia tra Domande e Stato che ha una componente temporale (A) o dovrebbe essere più statica, ma con un tabella cronologica orientata al registro sul lato (B).

(Nota: se volessi fare una versione pura di (A), allora Boofus ha ragione, probabilmente non inseriresti anche state_id nella tabella delle domande, poiché è ridondante; ma sarebbe sicuramente scomodo perché farebbe semplici domande per ottenere domande in uno stato particolare molto più difficili. Quindi hai una versione ibrida qui.)

In generale, se il requisito di conservare le informazioni storiche sullo stato è in realtà solo a scopo di controllo, ovvero se non verrà regolarmente interrogato dall'applicazione stessa, probabilmente è meglio andare con l'opzione B, perché è un po 'più semplice (esiste davvero solo la tabella "Domande", con una tabella di riferimento per gli stati e una tabella "log" per gli stati precedenti). Penso che questo mostri un po 'meglio le tue intenzioni.

Tuttavia, se la semantica dell'applicazione è più complessa (ad esempio, se hai domande come " mostra tutte le domande che sono state nello stato X nelle ultime 24 ore ... "), quindi un approccio come (A) potrebbe avere più senso. Sta essenzialmente trasformando lo stato di una domanda in un fatto dipendente dal tempo. Se lo fai, tieni presente che complica le cose: o tutte le tue domande sono più difficili e devono considerare il tempo, oppure devi preoccuparti di mantenere lo stato_id su Domande in sincronia con lo stato più recente nella tabella Domande. Se segui questa strada, potresti chiamarla " current_state " o qualcosa su Domande, quindi è chiaro che si tratta di una sorta di informazione derivata.

Answer 2

Potresti voler esplorare il web sull'argomento di "database temporali". Fondamentalmente, la memorizzazione della cronologia delle modifiche di qualsiasi variabile solleva gli stessi problemi, indipendentemente dal fatto che la variabile acquisisca lo stato della domanda o il peso della persona o altro.

In secondo luogo, penso che la tua domanda riguardi la progettazione di database e non la modellazione di dati concettuali. Se ho la giusta direzione, mi stai chiedendo quale design del tavolo è migliore.

Terzo, mi piace di più l'opzione B, ma dipende davvero da cosa farai con i dati.

Il motivo per cui ho chiesto informazioni sulla progettazione del database rispetto alla modellazione concettuale è che molto tempo fa ho adottato la pratica di utilizzare "entità e relazioni" per la modellazione concettuale dei dati associata all'analisi dei dati. Uso i termini "tabelle, colonne e righe" quando si discute della progettazione di database logici. Mantenere l'analisi e la progettazione separate risulta essere molto prezioso in grandi progetti. E non è così facile da fare come sembra.

Dovresti davvero aggiungere una freccia tra la tabella storica e la tabella di stato nel diagramma per l'opzione B. Il modo in cui il diagramma viene presentato, sembra quasi che la tabella storica sia una tabella disgiunta. Non è un problema in questo semplice esempio, ma se mantieni la stessa pratica quando passi ai database con dozzine di tabelle, finirai per confondere tutti coloro che guardano il diagramma.

Answer 3

Dopo aver disegnato tutte le relazioni, sono le stesse.

Non capisco perché tu abbia state_id nella tabella delle domande - dato che hai la tabella storica, avere lo stato nella tabella delle domande è ridondante e può lasciarti con dati non sincronizzati.

Mi sembra che se vuoi lo stato corrente su una domanda, lo fai

SELEZIONA State_ID DA Storico DOVE Question_id =? ORDINA PER Data DESC LIMIT 1

(o qualunque sia il metodo utilizzato da SQL per limitare a una sola riga)

Answer 4

Supponendo di avere buoni livelli di astrazione tra il database e il tuo OO, potresti prendere in considerazione la possibilità di estrarre la tabella di stato dal database e renderla un elenco in una classe. Non è necessariamente qualcosa che deve essere persistito.

Quindi, inserire la colonna Stato nella tabella Domande e la tabella di controllo.

Answer 5

Dici controllato, il che implica che desideri semplicemente conservare le informazioni storiche a fini di reportistica. Nel qual caso suggerirei che il diagramma B è il più chiaro, anche se probabilmente dovresti contrassegnare quello a molte relazioni tra Domande e Storico e anche Stato e Storico.

Per quanto riguarda gli aspetti pratici, se le circostanze sono come sopra, io stesso incapsulerei la funzionalità di inserimento Storico in un trigger di inserimento / aggiornamento su Domande e se il volume della tabella Domande e / o il numero di cambiamenti di stato sta per essere significativo vorrei prendere in considerazione l'inserimento della tabella storica in un database diverso. Ciò semplifica la gestione del database in un secondo momento. Normalmente sono diffidente nei confronti dei trigger poiché un utilizzo troppo zelante può portare a database difficili da mantenere (poiché non è immediatamente ovvio cosa stia succedendo) ma questo è un chiaro caso in cui sono adatti e sono una scelta superiore all'utilizzo logica dell'applicazione.

Per inciso entrambi i tuoi due diagrammi implicano che una domanda può entrare in ogni stato solo una volta (dal tuo PK) - dovresti considerare se questo è corretto come nella maggior parte del mondo reale verranno fatti errori e gli stati invertiti.

Answer 6

Non ho capito, come #Boofus, l'interesse di avere un campo state_id nella tabella delle domande.

Ho lavorato parecchio con questo "stato" concetti nella nostra stessa applicazione. Nelle situazioni più complesse, in cui dobbiamo seguire una cronologia degli stati completa e situazioni in cui un oggetto può avere più stati, stiamo utilizzando il seguente modello:

Per situazioni con più stati, l'idea è di verificare se il valore end_date è null (un'altra idea sarebbe quella di avere un campo booleano nella tabella Attivo). Non sottovalutare l'interesse di avere questo "stato multiplo" configurazione. Esempio:

Una domanda può essere

• chiuso e risolto

o

• chiuso e non risolto.

Ciò potrebbe corrispondere a 2 stati diversi:

• A "Chiuso e risolto" Stato

o

• A " Chiuso e non risolto " Stato

Ma penso che la soluzione migliore sarebbe quella di avere entrambi un

• A " Aperto / Chiuso " Stato

e

• A "Risolto / Non risolto" Stato

E per consentire alla domanda di avere più stati