Come memorizzare gli stati dei record (come in sospeso, completo, bozza, annullato ...)

Molte applicazioni richiedono che i record nelle loro tabelle abbiano uno stato, come "completo", "bozza", "annullato". Qual è il modo migliore per memorizzare questi stati? Per illustrare ciò che sto ottenendo qui è un esempio * molto breve).

Ho una semplice applicazione Blog e ogni post ha uno stato di: pubblicato, in bozza o in sospeso.

Per come la vedo io ci sono 2 modi per modellarlo nel database.

1. La tabella Posta ha un campo di testo che include il testo dello stato.
2. La tabella Post ha un campo di stato che contiene l'ID di un record nella tabella PostStatus

L'esempio Blog qui è un esempio molto semplice. Dove un enum (se supportato) potrebbe essere sufficiente. Tuttavia, vorrei che le risposte alla domanda prendessero in considerazione il fatto che l'elenco degli stati potrebbe cambiare in qualsiasi momento, in modo da poterne aggiungere o rimuovere altri.

Qualcuno può spiegare i vantaggi / gli svantaggi di ciascuno?

Saluti!

La mia scelta iniziale è che è meglio usare un'altra tabella e cercare lo stato come migliore per la normalizzazione e mi è sempre stato insegnato che la normalizzazione è buona per i database

Memorizzare lo stato come indice in un'altra tabella è una complicazione inutile. Memorizza lo stato direttamente nella tabella in modo leggibile. Nel codice dell'applicazione utilizzare costanti o un tipo di enumerazione. Ciò comporterà un codice applicazione più semplice e faciliterà il debug del livello dati.

Questo non denormalizza i dati, cambia semplicemente la rappresentazione. Se il database supporta direttamente le enumerazioni, utilizzarlo. In caso contrario, utilizzare un vincolo per limitare i valori della colonna. Avrai un vincolo in entrambi i casi: un vincolo diretto sui valori di colonna o un vincolo di chiave esterna.

Sì, potrebbe essere necessario presentare lo stato in modo diverso a utenti diversi. Questo è un problema di presentazione, da risolvere nel livello di presentazione, non nel livello di persistenza.

La memorizzazione del testo di stato non è una buona idea dell'IMO, dal momento che qualcuno potrebbe decidere che "completo" dovrebbe essere chiamato "finito" invece e quindi è necessario aggiornare il database, esaminare il programma se qualcuno ha codificato il testo ecc.

Quello che ho visto in molti programmi è un codice numerico (1 = nuovo, 2 = bozza, 3 = in convalida, 4 = completo, 99 = annullato) o un breve codice alfanumerico ("NUOVO", "DRA", "INV "," COM "," CAN "). Il successivo rende il codice (nel programma o nel database) più leggibile dall'uomo, il che è generalmente una buona cosa. D'altra parte, i codici numerici rendono facile fare confronti "maggiori di" o "minori di", ad esempio

select * from myrecords where status < Status.Complete;

Le tre regole dei database relazionali:

1. Normalizzare
2. Normalizzare
3. Normalizzare

Quindi la tua domanda risponde a se stessa. Mantenere lo stato all'interno della propria tabella e utilizzare GUID / UUID come ID . I GUID indicizzati sono molto veloci e risolvono i problemi intrinseci all'aumento dei numeri. Con un ID puoi fare cose interessanti come chiedere al DB tutti i post completati usando l'id, e poiché stai lavorando all'interno del paradigma db relazionale, è molto veloce. Se hai solo un campo, il DB deve scorrere su ogni singola riga e fare un confronto testuale, magari con il munging, e questo è molto lento.

I nomi dello stato dei post possono cambiare, più informazioni sullo stato dei post possono andare nella tabella, tutto funziona solo se si normalizza .

Ad esempio, è possibile aggiungere livelli di stato come informazioni aggiuntive, il che consentirebbe le menzioni di confronto di munizioni. Ma non dipendono dalla chiave per il posizionamento, consentendo di riorganizzare il livello di stato senza danneggiare l'integrità del DB. Puoi anche inserire livelli aggiuntivi, il che è piuttosto un trucco se hai il livello associato alla chiave di incremento automatico.

Sì, dovresti andare con l'opzione 2, con una tabella PostStatus.

A parte tutti i vantaggi menzionati in altre risposte.

Tenendo presente che è necessario aggiungere o rimuovere gli stati, è possibile avere una colonna "abilitata" nella tabella PostStatus, quindi se lo stato viene rimosso contrassegnare la colonna "abilitata" come "N", in questo modo sarà possibile aggiungere o rimuovere stati e anche i record esistenti rimarranno senza problemi.

Vorrei aggiungere alle risposte altrimenti approfondite che per la piena normalizzazione, un cambiamento nello stato di un'entità è in realtà modellato in un'entità separata, ad esempio denominato "statusChange".

Avresti bisogno di un ulteriore join con l'entità statusChange, ma vinci la possibilità di aggiungere ulteriori informazioni, come l'attore che esegue la modifica, i possibili commenti sul perché si è verificata la modifica e una data in cui viene eseguito lo statusChange e possibilmente anche quando diventa efficace.

L'uso del testo per lo stato nella tabella dei record non sarebbe probabilmente una buona idea in quanto ciò può cambiare e sarebbe difficile eseguire qualsiasi controllo di integrità dei dati su insert / update. Se stai utilizzando un DBMS con un tipo di dati enum, puoi invece usarlo (le prestazioni probabilmente non saranno compromesse ... a seconda).

Se il tuo stato richiede metadati (descrizione, creato da, nome descrittivo, ...) dovrai archiviare gli stati in una tabella separata e avere una chiave di stato nella tabella dei record (assicurati di utilizzare una chiave esterna). L'id non deve necessariamente essere un numero, ma solo il PK della tabella di stato. Inoltre, se gli stati sono nella propria tabella, è possibile condividerli tra tipi di record (tabelle), se applicabile. Non mi preoccuperei dei problemi di prestazioni con un JOIN nella tabella di stato.

Qualunque cosa tu faccia, assicurati di evitare gli stati magici (1 per attivo, 2 per cancellato, ...). Ciò si basa su documentazione e tradizione che hanno sempre la tendenza a perdersi su una linea temporale abbastanza ampia. Se stai usando gli ID numerici, assicurati che ci sia un'associazione testuale da qualche parte nel tuo db.

Dipende dallo scopo della progettazione del database.

Se si progetta il database semplicemente per supportare l'applicazione (vale a dire che gli oggetti (codice) sono padrone di tutti), utilizzare un'enumerazione (o un'enumerazione psuedo per le classi che non li supportano) e archiviare il nome dell'enum è un buona idea perché controlli ancora i valori consentiti attraverso l'enum e rendi anche la lettura della tabella un po 'più semplice quando sei costretto a visualizzare i dati grezzi (che non è così frequente se il codice governa effettivamente tutto). Ma se l'enumerazione è contrassegnata. Quindi di solito memorizzo il valore enum (numero intero).

Lo stato è molto importante, ogni volta che ricevi informazioni sui post dovrai ottenerne lo stato o vorrai filtrare i post per stato. Se hai lo stato in un'altra tabella, dovrai ottenere unioni per ottenere queste informazioni e quindi le prestazioni sono compromesse. Sicuramente dovresti avere lo stato nella stessa tabella. E mettici sopra un indice! Puoi ancora usare numeri interi come stato, o forse campo enum.

La soluzione corretta è utilizzare un archivio / sorgente di eventi con CQRS o una blockchain. Il problema con l'acquisizione di eventi in un RDB è che RDB memorizza un'istantanea di un singolo evento nel tempo e cose come "Stati / Stati" sono sequenze di mutazioni che si evolvono nel tempo