Devo archiviare False as Null in un campo di database booleano?

20

Supponiamo che tu abbia un'applicazione che ha un campo booleano nella sua Usertabella chiamata Inactive.

C'è qualcosa di intrinsecamente sbagliato nel solo memorizzare false come null? In tal caso, puoi spiegare quale dovrebbe essere il lato negativo? Ne ho discusso con qualcuno qualche mese fa ed entrambi abbiamo concordato che non dovrebbe importare fintanto che lo fai coerentemente in tutta l'app / database. Recentemente, qualcuno che conosco è stato enfatico sul fatto che "vero" trueo falsedovrebbe essere usato, ma in realtà non hanno dato una spiegazione del perché.

database-design null

— OMINUS
fonte

25

Wikipedia dice che

Null is a special marker used in Structured Query Language (SQL) to indicate that a data value does not exist in the database

questa è la saggezza accettata e non dovresti ridefinire il significato di Null nella tua applicazione. Sarà confuso per tutti gli altri che lavorano con il tuo codice.

— PersonalNexus,

10

Perché vorresti persino farlo? Perché non usare semplicemente un campo bit non annullabile e impostare il valore predefinito su false se questo è il comportamento desiderato invece di confondere il problema con un campo tri-state?

— JohnFx,

5

Esempio reale del perché questa è una pessima idea: SELECT * FROM foo WHERE bar = FALSEnon dà i risultati che ti aspetti.

— Blrfl,

2

Prendi in considerazione l'utilizzo di una colonna int con un valore predefinito 0 anziché un valore booleano. In questo modo se sorgono nuove condizioni (forse uno stato "in sospeso", ad esempio), non è necessario modificare la struttura del database.

— GrandmasterB,

4

Ma se memorizzi false come null come hai intenzione di archiviare FILE_NOT_FOUND ?! ( thedailywtf.com/Articles/What_Is_Truth_0x3f_.aspx )

— Ed James

50

C'è qualcosa di intrinsecamente sbagliato nel solo memorizzare false come null?

Sì.

In tal caso, puoi spiegare quale dovrebbe essere il lato negativo?

NULL non è uguale a False.

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

True and NULL è NULL (non False).

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

http://en.wikipedia.org/wiki/Null_(SQL)#Three-valued_logic_.283VL.29

http://technet.microsoft.com/en-us/library/cc966426.aspx

— S. Lott
fonte

3

Spiegazione corretta sul perché NULL è il valore che rappresenta l'assenza di valore.

— maple_shaft

2

il primo giorno del mio primo lavoro di sviluppo ha comportato il debug e la correzione di un errore come in questa domanda / risposta, reminiscenza +1

— tsundoku

1

Si noti che l'articolo stesso a cui si è collegati afferma che se l' nullelemento non è rilevante per la logica (come nel caso whatever OR TRUEo whatever AND FALSE, in cui nessun valore di whateverpuò modificare la condizione), allora l'espressione restituisce un valore. Non è un'ottimizzazione; è come funziona la logica a 3 valori . Qualsiasi DBMS che insiste per restituire UNKNOWN/ NULLper quelle espressioni è fondamentalmente rotto.

— cHao,

1

@ S.Lott, ma la memorizzazione di null anziché di false consente di risparmiare spazio ??

— Azerafati,

2

@Bludream: per i booleani, un campo nullable può effettivamente occupare più spazio, a seconda del DBMS. (È una quantità trascurabile in quasi tutti i casi, però.) Un booleano può essere rappresentato in un singolo bit ... ma un valore booleano nullable ha tre possibili valori (vero, falso e nullo), e quindi ha bisogno di più di un bit.

— cHao,

15

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

Anche se decidi su un modello come questo e lo fai in modo coerente in tutta la tua applicazione, ciò non va bene. Finirai in una situazione in cui non è chiaro agli occhi nuovi perché quel modello sia in atto o, più probabilmente, finirai in una situazione in cui quel modello viene inavvertitamente rotto.

— Jacob Maristany
fonte

5

Quello che altri hanno detto. 3 possibili valori non è un valore booleano.

Ma potresti avere un legittimo bisogno di 3 valori. Come (vero, falso, sconosciuto). Anche se questo è il caso, se ti piace l'ultra-normalizzazione non consentirai alcun valore nullo. Invece, memorizzerai un vero booleano in un'altra tabella con una relazione da 1 a 1. Un valore null può essere prodotto in una query da un join esterno "non riuscito", non da un valore null memorizzato fisicamente.

— Lord Tydus
fonte

al di fuori del regno della mia domanda booleana perché il vero falso sconosciuto sarebbe male se si usasse null per farlo? Al di là della mia domanda, i null sono generalmente da evitare? Perché?

— Ominus,

3

@Ominus: i nullità sono generalmente da evitare se sei un purista. Se usati come dovevano essere usati (come "non c'è valore qui" piuttosto che come un falso falso false), allora hanno il loro posto. Se non lo facessero, non esisterebbero. L'alternativa, come detto, è fondamentalmente avere un'intera altra tabella con solo la chiave primaria della riga e un singolo booleano (o int, o varchar, o cosa hai). Per ogni singolo campo che altrimenti renderebbe nullable. Pur essendo relazionalmente puro, è troppo contorto per la maggior parte degli scopi.

— cHao,

-3

È bool?un tipo booleano? No. È di tipo Nullable<T>dove Tè booleano. Un valore booleano nullable può avere 3 valori: true, false e null. Da usare boolo bool?dipende dalle tue esigenze. Potrebbe esserci un motivo legittimo in cui potresti dover utilizzare null ma un tipo che profuma di binario ma non conosci la risposta. Nell'esempio sopra,User.IsActivesembra chiaro. L'utente è attivo o no. Come sistema, potrebbe voler sapere se un utente è attivo o meno. Non ci dovrebbe essere "forse". Ma pensa a qualcosa come una bandiera caratteristica. La funzione è attivata? Le risposte potrebbero essere sì, no o non sono sicuro. Potresti avere una regola aziendale che si esplicita mostra il pulsante solo quando flag è impostato su true. Si potrebbe sostenere che bool sia di default falso, quindi perché creare bool nullable? Invertire il requisito: hai intenzione di impostare tutti i valori nell'origine dati su true?

— nullableTypes
fonte

2

questo post è piuttosto difficile da leggere (wall of text). Ti dispiacerebbe modificarlo in una forma migliore?

— moscerino del