SQL: stringa vuota vs valore NULL

Direi che NULL è la scelta corretta per "nessun indirizzo email". Ci sono molti indirizzi email "non validi" e "" (stringa vuota) è solo uno. Ad esempio "foo" non è un indirizzo email valido, "a @ b @ c" non è valido e così via. Quindi, solo perché "" non è un indirizzo email valido non c'è motivo di usarlo come valore "nessun indirizzo email".

Penso che tu abbia ragione nel dire che "" non è il modo corretto per dire "Non ho un valore per questa colonna". "" è un valore.

Un esempio di dove "" potrebbe essere un valore valido, separato da NULL potrebbe essere il secondo nome di una persona. Non tutti hanno un secondo nome, quindi è necessario distinguere tra "nessun secondo nome" ("" - stringa vuota) e "Non so se questa persona ha un secondo nome o no" ( NULL ). Ci sono probabilmente molti altri esempi in cui una stringa vuota è ancora un valore valido per una colonna.

Pur condividendo i suddetti commenti, aggiungerei questo argomento come motivazione primaria:

1. È ovvio per qualsiasi programmatore che osserva un database che un campo contrassegnato NULL è un campo facoltativo. (cioè il record non richiede dati per quella colonna)
2. Se contrassegni un campo NOT NULL, qualsiasi programmatore dovrebbe presumere intuitivamente che si tratta di un campo obbligatorio.
3. In un campo che consente i valori null, i programmatori dovrebbero aspettarsi di vedere i valori nulli anziché le stringhe vuote.

Per motivi di codifica intuitiva autodocumentazione, usa NULL invece di stringhe vuote.

Utilizza Null.

Non ha senso archiviare un valore di "", semplicemente facendo il campo nella tabella nullable. Rende le domande più ovvie anche.

Quale query SQL è più ovvia e leggibile se si desidera trovare utenti con un indirizzo email?

1. SELECT * FROM Users WHERE email_address != ''

2. SELECT * FROM Users WHERE email_address IS NOT NULL

3. SELECT * FROM Users WHERE email_address != '' and email_address IS NOT NULL

Direi 2 è. Sebbene 3 sia più robusto nei casi in cui sono memorizzati dati non validi.

Per il caso dell'indirizzo email sul modulo, che è opzionale, dovrebbe essere riportato anche nella tabella. In SQL, è un campo nullable, il che significa che non è noto.

Non riesco a pensare ad alcun valore commerciale ragionevole nell'archiviazione di una stringa vuota in una tabella diversa dalla semplice progettazione errata. È come memorizzare un valore di stringa di 'NULL' o 'BLANK', e con gli sviluppatori si assume che è null o una stringa vuota. Per me, è un cattivo design. Perché memorizzarlo quando c'è NULL ??

Utilizza NULL e renderai tutti più felici.

ULTERIORI INFORMAZIONI:

SQL utilizza un sistema logico a tre valori: True, False e Sconosciuto.

Per una spiegazione migliore e più dettagliata, consiglio agli sviluppatori di leggere: Query SQL - oltre VERO e FALSO .

Penso che la risposta di Dean Hardings lo copra davvero bene. Detto questo vorrei menzionare che quando si parla di NULL contro stringhe vuote a livello di DB, si dovrebbe riflettere sugli altri tipi di dati. Vuoi memorizzare una data minima quando non viene fornita alcuna data? o -1 quando non viene fornito alcun INT? Memorizzare un valore quando non hai alcun valore significa che devi quindi tenere traccia di un intero intervallo di non valori. Almeno uno per ogni tipo di dati (possibilmente più come si ottengono i casi in cui -1 è un valore effettivo quindi è necessario avere qualche alternativa ecc.). Se hai bisogno / vuoi fare qualcosa di "fudgy" a livello di applicazione è una cosa, ma non è necessario inquinare i tuoi dati.

Sfortunatamente, Oracle ha confuso la rappresentazione della stringa VARCHAR di lunghezza zero con la rappresentazione di NULL. Sono entrambi rappresentati internamente da un singolo byte con valore zero. Ciò rende la discussione ancora più difficile.

Gran parte della confusione che circonda NULL riguarda la . Considera il seguente pseudocodice:

if ZIPCODE = NULL
    print "ZIPCODE is NULL"
else if ZIPCODE <> NULL
    print "ZIPCODE is not NULL"
else print "Something unknown has happened"

per la specifica domanda tecnica, il problema non è null vs empty-string, è un errore di convalida . Una stringa vuota non è un indirizzo email valido!

per la domanda filosofica, la risposta è simile: conferma i tuoi input. Se una stringa vuota è un valore valido per il campo in questione, allora aspettalo e codice per esso; in caso contrario, usa null.

Una stringa vuota sarebbe un input valido per rispondere alla domanda: che cosa ha detto il mimo alla giraffa?

Potrei pensare a un motivo per avere NULL e la stringa vuota:

• Hai indirizzi email validi: [email protected]
• Non ne hai (e probabilmente dovresti chiederne uno): NULL
• Sai che questa persona non ha un indirizzo email: Empty String.

Tuttavia, non lo consiglierei e userei un campo separato per chiedere se sai che nessuno è esistente.

La domanda, a quanto ho capito, è che le interpretazioni di NULL e stringa vuota dovrebbero essere scelte. Ciò dipende dal numero di stati in cui può trovarsi il campo particualar.

L'interpretazione dipende da come si accede al database. Se c'è un livello nel codice che estrae completamente il database, allora la scelta di qualsiasi criterio (incluso il two-coulmn) che funziona è completamente accettabile. (Tuttavia, documentare chiaramente la politica è importante). Tuttavia, se si accede al database in più punti, è necessario utilizzare uno schema molto semplice, poiché il codice sarà più difficile da mantenere e potrebbe essere errato in questo caso.

Fondamentalmente a livello logico non c'è differenza tra il valore "non valido" e "nessun input dell'utente", sono solo tutti "casi speciali" il più delle volte. Errore.

Avere null prende spazio addizionale: ceil (columns_with_null / 8) in byte / per riga.

Le celle vuote e null sono entrambi modi per contrassegnare che qualcosa è sbagliato / dovrebbe essere l'impostazione predefinita. Perché avresti bisogno di 2 stati "sbagliati"? Perché utilizzare NULL se occupano spazio aggiuntivo e significano esattamente le stringhe vuote? Ciò introdurrà solo confusione e ridondanza quando stai avendo due cose che significano (che potrebbe significare) esattamente la stessa cosa, è facile dimenticare che dovresti usare NULL invece di stringhe vuote (se per esempio l'utente ha omesso alcuni campi).

E i tuoi dati possono diventare un casino. In un mondo perfetto diresti "i dati saranno sempre corretti e me lo ricorderò" ... ma quando le persone devono lavorare in una squadra e non tutti sono esattamente al tuo livello, non è raro vedere WHERE (aa. xx < > '' AND bb.zz NON È NULL)

Quindi, invece di correggere i membri del mio team ogni due giorni, impongo semplicemente una semplice regola. Nessun valore null, MAI!

Il conteggio dei valori NON NULL è più veloce ... una domanda semplice è a cosa avresti bisogno per farlo?

Tendo a vederlo non dalla prospettiva del DB ma dal punto di vista del programma. So che questa domanda è per il clic SQL, ma in realtà, quanti utenti accedono direttamente ai dati più a lungo?

In un programma non mi piace null / nothing. Ci sono alcune eccezioni ma sono proprio questo. E quelle eccezioni sono solo cattive implementazioni.

Quindi, se l'utente non ha inserito l'e-mail, dovrebbe esserci qualcosa che determina se questo è valido o meno. Se un'e-mail vuota va bene, viene visualizzata una stringa vuota. Se l'utente non ha inserito un'email e questo viola una regola, l'oggetto dovrebbe indicarlo.

L'idea di avere un significato nullo è vecchia scuola ed è qualcosa che i programmatori moderni devono risolvere.

Anche nella progettazione del DB, perché il campo email non può consentire null e avere una stringa di lunghezza zero e avere un altro campo che indica se l'utente inserisce qualcosa? C'è un po 'di più da chiedere a un DBMS? Il DB non dovrebbe, a mio avviso, gestire né la logica aziendale né la logica di visualizzazione. Non è stato costruito per questo e quindi fa un lavoro molto scarso nel maneggiarlo.

Non penso che importi molto, ma mi piace di più quando c'è il NULL.

Quando visualizzo i dati visualizzati in una tabella (come in SQL Server Management Studio), posso distinguere meglio un valore mancante se dice NULL e lo sfondo è di colore diverso.

Se vedo uno spazio vuoto, mi chiedo sempre se è veramente vuoto o ci sono spazi bianchi o alcuni caratteri invisibili. Con NULL è garantito vuoto a prima vista.

Di solito non distinguo i valori nell'applicazione, perché è inaspettato e strano che NULL e stringa vuota significhino qualcosa di diverso. E la maggior parte delle volte, prendo un approccio difensivo e mi occupo solo di entrambi gli stati. Ma per me come uomo, NULL è più facile da elaborare quando si guardano i dati.