Uso di booleani in un database

Vedo i tuoi colleghi a proposito della possibilità di alcuni casi in cui un bool potrebbe alla fine diventare più di true o false - in alcuni casi, ma non proprio questo. Ma vorrei suggerire contro di andare sulla rotta varchar . Utilizza una tabella di ricerca con valori validi e una integer id con un vincolo univoco sui valori validi o un enum come suggerito nei commenti / altre risposte.

abbiamo "apparentemente" campi di bool in tutto il nostro database, ma in realtà sono stringhe. Con la nostra applicazione, che è a 4 livelli, con un parametro stringa passato attraverso i livelli, non hai (potenzialmente) alcuna idea di quali siano i valori "validi" della stringa.

Esempio:

useMaster varchar(1).

Penso che questo si adatti molto meglio come bool di una stringa. Nel mio caso è "master" o "transazione". Tuttavia, poiché stiamo usando un varchar, qual è il mio livello di proc 4 in attesa di significare master? Non ho idea dall'interfaccia utente E '"Y" per sì? è "T" per vero? Se avessi indovinato uno di questi, avrei sbagliato, perché in realtà era "M" per il maestro. Nel mio caso abbiamo fondamentalmente:

If (@userMaster = 'M')
    // use master
else
    // use transaction

Nessuna delle opzioni che avevo immaginato era un valore valido per ottenere master come volevo. Devo eseguire il drill down su 4 livelli di codice per determinare cosa si aspettava effettivamente il proc.

Le stringhe magiche sono cattive vorrei altamente sconsigliare usandoli.

is there any reason that representing this value as a boolean should be avoided?

No.

Data la situazione che hai descritto, un booleano è un buon candidato per lo stato attivo / inattivo.

Alternativa:

Suggerirei comunque di utilizzare un campo data / ora / data / ora per registrare lo stato attivo. Hai detto che vuoi mantenere una cronologia di uffici inattivi. Se si dispone di una colonna denominata activeTo con tipo datetime che consente valori null, è possibile utilizzare tale campo per sapere se l'ufficio è ancora valido.

• null o la data futura è attiva;
• qualsiasi data del passato non è attiva;

Ciò ti consentirebbe di sapere quando l'ufficio è stato reso inattivo.

Alternativa 2:

Potresti anche tenere tutti gli uffici in 1 tabella e avere un'altra tabella per rappresentare quelli attivi. Solo una colonna ID. Puoi usare JOIN per filtrare le tabelle inattive. Non ho usato questo approccio quindi non so se ci sono problemi che mi mancano.

Alternativa 3:

Come suggerito da qualcun altro, è possibile aggiungere una tabella per contenere tutti i valori possibili per lo stato dell'ufficio. Ciò consente di aggiornare le possibilità in molti modi e fornire all'utente una rappresentazione più significativa rispetto a Y o T.

Ti suggerisco di esaminare diverse opzioni e cercare di fare la migliore ipotesi possibile. Hanno tutti vantaggi e svantaggi. Il contesto e l'equilibrio sono importanti.

L'uso di varchar(1) per qualcosa che è uno dei due valori è daft - questo è a cosa serve un campo bit .

Tuttavia, se il requisito cambia e sono necessari ulteriori valori di stato, potrebbe essere preferibile utilizzare un enum nel codice e memorizzare il valore come numero intero. In questo modo, non dovrai tornare indietro per modificare la struttura del database per memorizzare i nuovi valori.