Come gestire le colonne di stato nella progettazione di tabelle

Ecco le 4 possibili soluzioni a cui posso pensare

1. codifica tutto in una colonna, usando un tipo di numero come bitset

   pro:

   • la più piccola quantità di memoria necessaria

   • facilmente estendibile fino al punto in cui si raggiungono n flag, dove 2 ^ n è il valore massimo del tipo di numero scelto

   con:

   • le query per tutti gli articoli con uno stato specifico sono difficili, dal momento che la maggior parte dei dialetti sql non supportano le operazioni sui bit

   • nessuna indicizzazione per un singolo flag, una query per tutti gli elementi con lo stato specifico di s comporterà sempre una scansione completa della tabella

2. codifica tutto in una colonna, usando una stringa di "0" e "1"

   pro:

   • ancora molto compatto in memoria
   • facilmente estensibile, come il primo approccio, ma nessun limite inerente n

   con:

   Le query
   • non sono così difficili come sopra, ma richiedono operazioni con le stringhe
   • ancora nessuna indicizzazione

3. usa una colonna diversa per ogni stato

   pro:

   • le query indicizzate sono facili
   I risultati della query
   • sono facilmente leggibili / non richiedono una decodifica specifica

   con:

   • estensibile solo modificando lo schema
   • ha bisogno di più spazio di archiviazione

4. usa una tabella di link (la soluzione di Michael Durrant)

   pro:

   • può essere esteso in fase di esecuzione, senza alcuna modifica dello schema
   • le query indicizzate sono possibili

   con:

   Le query
   • sono più complicate / richiedono un join
   • gli inserimenti e gli aggiornamenti sono più complicati, invece di un record ora devi aggiungere due o più record per archiviare le stesse informazioni

Quindi tutte queste soluzioni hanno diversi compromessi e dovresti prendere la decisione in base ai casi d'uso / query che ti aspetti e alla quantità di estensibilità di cui hai bisogno.

Per un database relazionale ti suggerirei di archiviarli in tabelle status e item_statuses separate che hanno le loro chiavi primarie.

La tabella "join" tra item e status , ad es. item_statuses ha le chiavi di ciascuna delle due tabelle, ad es. item_id e status_id . Ha anche la sua chiave primaria (' id ') poiché la mia esperienza dice che hanno sempre una chiave primaria che non ha alcun significato commerciale e che entrambe le altre chiavi hanno un significato commerciale quindi il loro composto non è una buona chiave primaria. / p>

L'archiviazione di valori letterali come varchar può facilmente portare a inganni, errori di battitura e altri problemi.

Se si dispone di uno stato che può essere più stati diversi, ma mai più di uno alla volta, quindi disporre di una colonna. Altrimenti, le colonne separate sono obbligatorie.

Non vuoi mai memorizzare più cose in una singola colonna. Interrogarci contro sarebbe un incubo. Potresti solo pensare di caricare i dati in un modo particolare ora, ma in 3 anni quando qualcuno ti chiede di eseguire un rapporto in un modo specifico e ti rendi conto che non c'è un modo reale per farlo perché ci sono 10 cose tutte memorizzate in una colonna concatenata, hai una pesante riprogettazione sulle tue mani.

L'uso di una singola colonna suona appropriato, a condizione che i diversi valori di stato siano stati legittimamente differenti della stessa cosa. Questo è fondamentalmente ciò che ha detto anche Razethestray.

Se crei una tabella di ricerca dello stato separata come suggerisce Michael Durrant, puoi aggiungere facoltativamente le varie colonne booleane a quella tabella.

L'aggiunta di colonne di flag aggiuntive a una tabella di ricerca non è una tecnica comune, nella mia esperienza, ma ho provato un po 'e mi piace come mi permette di mantenere magicamente il codice dell'applicazione sapendo che lo stato "In corso" significa " non è possibile aggiungere elementi ", ad esempio. Invece, potrei avere una colonna AllowsAddingItems sulla mia tabella di stato, e il valore in quella colonna per lo stato "In corso" sarebbe falso. In questo modo, il mio codice applicazione non deve essere consapevole di quali siano tutti i diversi stati possibili; controlla solo che l'attributo AllowsAddingItems sia associato allo stato corrente.