In che modo un cognome Null può causare problemi in molti database?

Ho letto un articolo sulla BBC. Uno degli esempi che hanno detto è che le persone con cognome "Null" hanno problemi con l'inserimento dei loro dettagli in alcuni siti Web.

Non viene fornita alcuna spiegazione sull'errore che devono affrontare.

Ma per quanto ne so la stringa "Null" e il valore Null effettivo sono completamente diversi (dal punto di vista del database).

Perché ciò causerebbe problemi in un database?

Non causa problemi al database. Causa problemi nelle applicazioni scritte da sviluppatori che non comprendono i database. Alla radice del problema è che molti software relativi al database visualizzano un record NULL come stringa NULL. Quando un'applicazione si basa quindi sulla forma di stringa di un record NULL (probabilmente utilizzando anche operazioni di confronto senza distinzione tra maiuscole e minuscole), tale applicazione considererà qualsiasi "null"stringa come NULL. Di conseguenza un nome Null sarebbe considerato inesistente da tale domanda.

La soluzione è dichiarare colonne non nulle come NOT NULLnel database e non applicare le operazioni di stringa ai record del database. La maggior parte delle lingue dispone di eccellenti API di database che rendono superflue le interfacce a livello di stringa. Dovrebbero essere sempre preferiti, anche perché rendono meno probabili 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 Nullviene erroneamente interpretato come un NULLvalore, il sistema potrebbe 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, probabilmente anche il database è aperto all'iniezione SQL AKA l' attacco Bobby Tables . Un altro passo nella 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 si conforma ai nostri presupposti. Ciò è particolarmente evidente quando si tenta di internazionalizzare l'applicazione. Alla fine, dobbiamo garantire che le nostre applicazioni gestiscano e codifichino correttamente i nostri dati . Spetta al business decidere quante risorse dedichiamo per supportare casi limite sempre più complicati. Mentre sostengo pienamente l'essere inclusivo, capirò se l'azienda decide che "l'artista formalmente noto come Prince" deve usare un carattere Unicode per rappresentare il suo nome nel nostro database.

Bene, prima di essere inserito nel database, è un elemento DOM, quindi una variabile javascript è passata, convalidata e manipolata, quindi un valore JSON, quindi una variabile in qualunque libreria JSON back-end che stai usando, quindi una variabile passata, convalidato e manipolato nel linguaggio di programmazione back-end, quindi un elemento di una sorta di DAO, quindi parte di una stringa SQL. Quindi, per ripristinare il valore, fai tutto al contrario. Ci sono molti posti in cui i programmatori possono commettere errori, e di solito molti senza il vantaggio della digitazione statica.

Molto probabilmente è un problema di programmazione. Se guardi questa risposta qui su come vengono passati i NULL, potresti facilmente causare un comportamento indesiderato se fossi "Mr. Null".

https://stackoverflow.com/questions/4620391/mysql-and-php-insert-null-rather-than-empty-string

Si può vedere che se alcuni elementi di dati fossero passati come NULL, i dati sarebbero interpolati come un database null nel database.

"NULL"! = Database Null

Alcuni casi d'uso e comportamento correlato ...

Supponiamo che il cognome sia stato contrassegnato nel database come non nullo, ora quando i dati vengono inseriti verranno interpretati come NULL e fallirà l'inserimento.

Un altro caso è supponiamo che il cognome fosse nullable nel database. Mr. NULL viene inserito e trasformato in DBNull.Value che non è lo stesso di "NULL". Dopo l'inserimento non riusciamo a trovare Mr. Null perché il suo cognome non è "NULL" ma in realtà un valore null del database.

Quindi, questi sarebbero 2 casi di problemi. Come sottolinea @Amon, i database stessi non hanno problemi con i null, anche se si dovrebbe capire come vengono gestiti i null in ciascuna istanza RDMS in quanto vi saranno differenze tra i diversi fornitori.

Vorrei attribuire il problema alla programmazione sciatta e alla cattiva progettazione di alcune implementazioni di SQL. "Null" il nome deve essere sempre presentato e interpretato tra virgolette. null, il valore del database, deve essere sempre presentato senza virgolette; ma quando si scrive un codice ad-hoc, è facile scivolare nel paradigma del "tutto farà" e accettare le cose ritenute una stringa in una forma non quotata.

Ciò è aggravato dal fatto che altri tipi di dati; i numeri, ad esempio, possono e sono accettati in entrambe le forme perché l'interpretazione non è ambigua.

Un problema, fondamentalmente, è che al termine "null" vengono applicati due diversi concetti di database, a volte usando il contesto per distinguerli:

1. Qualcosa non ha un valore noto
2. Si sa che qualcosa non ha valore

Mentre il contesto a volte può bastare per distinguere tra quei concetti, ci sono momenti in cui non lo fa. Se si utilizza un record per contenere una query di ricerca, ad esempio, dovrebbe esserci una differenza tra dire "Voglio qualcuno con il nome di [qualunque cosa], senza cognome", rispetto a "Voglio qualcuno il cui nome è [ comunque] ma il cui cognome è sconosciuto. " Molti motori di database hanno una propensione verso un significato o l'altro, ma non sono tutti uguali. Il codice che prevede che un motore di database funzioni in un modo potrebbe non funzionare correttamente 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 SQL può scrivere un filtro WHERE u.lastname != 'NULL'. A causa del modo in cui funziona SQL, questo sembrerà verificare se u.lastname IS NOT NULL: tutti i NULLrecord vengono filtrati. NULLRimangono tutti i non record.

Tranne ovviamente per i record in cui u.lastname == 'NULL', ma potrebbe non esserci stato alcun record disponibile durante i test.

Ciò 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 NULLconformità con i parametri e qualcuno nota "hey, se passo la stringa NULL, fa esattamente quello che voglio! "