Devo memorizzare False come Null in un campo di un database booleano?

Is there anything inherently wrong with just storing false as null?

Sì.

If so can you please explain what the down side should be?

NULL non è lo stesso di False.

Per definizione, i confronti (e la logica) che coinvolgono NULL dovrebbero restituire valori di NULL (non Falso). Tuttavia, le implementazioni SQL possono variare.

True and NULL è NULL (non Falso).

True and NULL or False è NULL (non Falso).

link

link

Consentendo null in un campo booleano, si sta trasformando una rappresentazione binaria (true / false) in una rappresentazione a tre stati (true, false, null) in cui le voci "null" sono indeterminate. Il valore "null" non è né "vero" né "falso". Quale motivo dovresti aumentare la tua rappresentazione per essere inaccurata?

Anche se decidi su un pattern come questo e lo fai in modo coerente in tutta la tua applicazione, questo non lo rende okay. Finirai in una situazione in cui non è chiaro agli occhi nuovi perché quel modello è a posto o, più probabilmente, finirai in una situazione in cui quel modello è inavvertitamente rotto.

Che altro hanno detto. 3 valori possibili non sono booleani.

Ma potresti avere un legittimo bisogno di 3 valori. Ad esempio (vero, falso, sconosciuto). Anche se questo è il caso, se si è in ultra-normalizzazione non si consentirà alcun valore nullo. Invece memorizzerai un vero booleano in un'altra tabella con una relazione 1 a 1. Un valore nullo potrebbe essere prodotto in una query da un join esterno "non riuscito", non da un valore nullo memorizzato fisicamente.

bool? è un tipo booleano? No. È di tipo Nullable<T> dove T è booleano. Un valore booleano nullable può avere 3 valori: true, false e null. Per utilizzare bool o bool? dipende dal tuo fabbisogno. Potrebbe esserci una ragione legittima in cui potrebbe essere necessario utilizzare null ma un tipo che ha un odore come binario ma non si conosce la risposta. Nell'esempio precedente, User.IsActive sembra chiaro. L'utente è attivo o no. Come sistema, potrebbe voler sapere se un utente è attivo o meno. Non dovrebbe esserci "forse". Ma pensa a qualcosa come una bandiera caratteristica. La funzione è attiva? Le risposte potrebbero essere sì, no o non sono sicure. Potresti avere una regola aziendale che indica solo il pulsante quando il flag è impostato su true. Si potrebbe obiettare che bool è di default falso, quindi perché creare un bool nullable? Inversa il requisito: hai intenzione di impostare tutti i valori nell'origine dati su true?