Ho letto un articolo sulla BBC. Uno degli esempi che hanno detto è che le persone con il cognome "Null" hanno problemi ad inserire i loro dettagli in alcuni siti web.
Non viene fornita alcuna spiegazione sull'errore che stanno affrontando.
Ma per quanto ne so, la stringa "Null" e il valore Null attuale sono completamente diversi (dal punto di vista del database).
Perché ciò potrebbe causare problemi in un database?
Non causa problemi di database. Causa problemi nelle applicazioni scritte da sviluppatori che non capiscono i database. Alla radice del problema è che molti software relativi al database mostrano un record NULL come stringa NULL . Quando un'applicazione si basa sulla forma di stringa di un record NULL (probabilmente utilizzando anche operazioni di confronto senza distinzione tra maiuscole e minuscole), una tale applicazione considererà qualsiasi "null" stringa come NULL. Di conseguenza, un nome Null non dovrebbe essere considerato da tale applicazione.
La soluzione è dichiarare colonne non nulle come NOT NULL nel database e non applicare le operazioni con le stringhe ai record del database. La maggior parte delle lingue ha eccellenti API di database che rendono superflue le interfacce a livello di stringa. Devono sempre essere preferiti, anche perché fanno meno probabile altri errori come l'iniezione SQL.
Per rispondere alla tua domanda specifica ci sono molti passaggi lungo la catena di eventi tra un modulo web e il database. Se il cognome Null è erroneamente interpretato come valore NULL , il sistema può rifiutare un nome perfettamente valido come non valido. Questo può accadere a livello di database come spiegato da amon . Per inciso, se questo è il problema specifico, anche il database è probabilmente aperto all'iniezione SQL AKA l'attacco Bobby Tables . Un altro passaggio della catena che potrebbe causare problemi è il processo di serializzazione .
Nel complesso l'articolo riguardava un problema più grande. Il mondo è un grande luogo disordinato che non sempre è conforme alle nostre ipotesi. Ciò è particolarmente evidente quando si tenta di internazionalizzare la propria applicazione. Alla fine della giornata, dobbiamo garantire che le nostre applicazioni gestiscano e codificano correttamente i nostri dati . Spetta all'azienda decidere quante risorse dedicare al supporto di casi limite sempre più complicati. Mentre sostengo pienamente di essere inclusivo, capirò se l'azienda decide che "l'artista formalmente conosciuto come Prince" ha bisogno di usare un personaggio Unicode per rappresentare il suo nome nel nostro database.
Bene, prima che venga inserito nel database, è un elemento DOM, quindi una variabile javascript passata, convalidata e manipolata, quindi un valore JSON, quindi una variabile in qualsiasi libreria JSON di backend che stai utilizzando, quindi una variabile passato, validato e manipolato nel tuo linguaggio di programmazione back-end, quindi un elemento di una sorta di DAO, quindi parte di una stringa SQL. Quindi, per recuperare il valore, fai tutto al contrario. Sono molti i luoghi in cui i programmatori possono commettere errori, e in genere molti di essi senza il vantaggio della digitazione statica.
Molto probabilmente è un problema di programmazione. Se guardi questa risposta qui su come vengono trasmessi i NULL, potresti facilmente causare un comportamento indesiderato se tu fossi "Mr. Null".
Si può vedere che se qualche elemento di dati è stato passato come NULL i dati sarebbero interpolati come un database nullo nel database.
"NULL"! = Database Null
Alcuni casi d'uso e relativi comportamenti ...
Diciamo che il cognome è stato contrassegnato nel database come non null, ora quando i dati sono inseriti sarà interpretato come un NULL e fallirà l'inserimento.
Un altro caso è supponiamo che il cognome fosse annullabile nel database. Mr. NULL viene inserito e viene trasformato in DBNull.Value che non è lo stesso di "NULL". Dopo l'inserimento non possiamo trovare Mr. Null perché il suo cognome non è "NULL" ma in realtà è un valore null del database.
Quindi, quelli sarebbero 2 casi di problemi. Come sottolinea @Amon, i database stessi non hanno problemi con i valori null, sebbene si debba comprendere come vengono gestiti i valori null in ogni istanza RDMS in quanto vi saranno differenze tra diversi fornitori.
Attribuirei il problema a una programmazione scadente ea una progettazione scadente di alcune implementazioni di SQL. "Null" il nome dovrebbe sempre essere presentato e interpretato con le virgolette. null, il valore del database, dovrebbe sempre essere presentato senza virgolette; ma quando si scrive codice ad hoc, lo è è facile scivolare nel paradigma "qualsiasi cosa farà" e accettare cose che si credono essere una stringa in forma non quotata.
Ciò è aggravato dal fatto che altri tipi di dati; numeri per esempio, può e sono accettati in entrambe le forme perché l'interpretazione è inequivocabile.
Un problema, fondamentalmente, è che il termine "null" viene applicato a due concetti di database diversi, a volte usando il contesto per distinguerli:
Mentre il contesto a volte può essere sufficiente per distinguere tra questi concetti, ci sono momenti in cui in realtà no. Ad esempio, se si utilizza un record per contenere una query di ricerca, dovrebbe esserci una differenza tra dire "Voglio qualcuno con il nome di [qualunque cosa], senza cognome", contro "Voglio qualcuno il cui nome è [ qualunque] ma il cui cognome è sconosciuto. " Molti motori di database hanno una tendenza verso un significato o l'altro, ma non sono tutti uguali. Il codice che prevede che un motore di database possa funzionare in un modo potrebbe funzionare male se eseguito su un motore diverso che funziona in modo diverso.
La maggior parte delle risposte esistenti si concentra sulle parti non SQL di un'applicazione, ma potrebbe esserci un problema anche in SQL:
Se viene richiesto di filtrare i record in cui il cognome di un utente non è disponibile, qualcuno che non capisce molto bene l'SQL può scrivere un filtro WHERE u.lastname != 'NULL' . A causa del modo in cui funziona SQL, questo apparirà per verificare se u.lastname IS NOT NULL : tutti i NULL record vengono filtrati. Restano tutti i record non NULL .
Tranne, naturalmente, per i record in cui u.lastname == 'NULL' , ma potrebbe non esserci alcun record disponibile durante il test.
Questo diventa più probabile se l'SQL è generato da una sorta di framework, in cui tale framework non espone un modo facilmente accessibile per verificare la non- NULL -ness con i parametri, e qualcuno nota "hey, if I passa nella stringa NULL , fa esattamente quello che voglio! "