Wie verursacht ein Nachname von Null in vielen Datenbanken Probleme?


71

Ich habe einen Artikel über BBC gelesen . Eines der genannten Beispiele war, dass Personen mit dem Nachnamen "Null" Probleme haben, ihre Daten auf einigen Websites einzugeben.

Es wird keine Erklärung für den Fehler gegeben, dem sie gegenüberstehen.

Aber soweit ich weiß, ist der String 'Null' und der tatsächliche Nullwert (aus Datenbanksicht) völlig unterschiedlich.

Warum würde dies Probleme in einer Datenbank verursachen?


2
Dies ist ein ziemlich berühmter Blog-Artikel über Annahmen, die Programmierer über Namen machen, geschrieben von einer der Personen, die in diesem BBC-Artikel zitiert werden: kalzumeus.com/2010/06/17/…
Jörg W Mittag



4
Als ich diesen Typen zum ersten Mal im Fernsehen sah, nahm ich an, dass es sich um einen Datenbankfehler handelte. Dann fand ich heraus, dass es tatsächlich sein Name ist.
Nate Eldredge

3
@JarrodRoberson Wie können Sie angesichts der Beschreibung der Probleme, mit denen "Jennifer Null" konfrontiert ist, und der in dem Link, den das OP gepostet hat, genannten Ähnlichkeit sagen, dass die gesamte Prämisse falsch ist? Es ist ein echtes Problem, vor dem echte Endbenutzer stehen.
Gort the Robot

Antworten:


102

Es verursacht keine Datenbankprobleme. Es verursacht Probleme in Anwendungen, die von Entwicklern geschrieben wurden, die Datenbanken nicht verstehen. Die Ursache des Problems liegt darin, dass in vielen datenbankbezogenen Programmen ein NULL-Datensatz als Zeichenfolge angezeigt wird NULL. Wenn sich eine Anwendung dann auf die Zeichenfolgenform eines NULL-Datensatzes stützt (wahrscheinlich auch bei Vergleichsoperationen ohne Berücksichtigung der Groß- und Kleinschreibung), betrachtet eine solche Anwendung eine beliebige "null"Zeichenfolge als NULL. Folglich würde ein Name Null von dieser Anwendung als nicht vorhanden angesehen.

Die Lösung besteht darin, Nicht-Null-Spalten wie NOT NULLin der Datenbank zu deklarieren und keine Zeichenfolgenoperationen auf Datenbankdatensätze anzuwenden. Die meisten Sprachen verfügen über hervorragende Datenbank-APIs, die Schnittstellen auf Zeichenfolgenebene überflüssig machen. Sie sollten immer bevorzugt werden, da sie auch andere Fehler wie SQL-Injection weniger wahrscheinlich machen.


30
In diesem Fall führt das Ausfüllen eines Feldes NOT NULLmit Nachnamen jedoch zu einer ganzen Reihe von Problemen für andere Personen , wenn Sie den betreffenden Artikel lesen . "Einige Personen haben nur einen einzigen Namen, keinen Vor- und Nachnamen."
MikeTheLiar

41
@Darkhogg Viele Leute sind sich darüber nicht einig, aber ich denke, dass Namen wie E-Mail-Adressen sind. Machen Sie sich nicht die Mühe, sie zu validieren, geben Sie dem Benutzer ein einziges Textfeld und lassen Sie ihn setzen, was er will. Dies ist eine Information, die ich, wenn ich sie wirklich brauche, auf eine Weise von Ihnen erhalte, die mit Sicherheit richtig ist.
MikeTheLiar

8
@mikeTheLiar Ich kenne den Namen dafür nicht, aber es gibt eine ganze Reihe von Fehlern, die sich aus der Erstellung übermäßig restriktiver Regeln für Daten ergeben. Oft werden Postleitzahlen und Telefonnummern in Anwendungen und Datenbanken als numerisch definiert. Sie sind nicht wirklich Zahlen, weil es keinen Sinn macht, mit ihnen mathematische Operationen durchzuführen. Wenn also jemand versucht, eine kanadische Adresse einzugeben, steckt er fest.
JimmyJames

19
@JimmyJames Ja, Postleitzahlen werden als Zahlen gespeichert, und plötzlich hat jeder, der hier lebt, eine Postleitzahl zur Basis 8. "Wenn Sie nicht damit rechnen, ist es eine Zeichenfolge, Punkt."
MikeTheLiar

8
@mikeTheLiar. Das Problem bei der Behandlung von Namen als einzelne Zeichenfolge (normalerweise vorzuziehen, da stimme ich zu) besteht darin, dass eine alphabetische Sortierung nach Nachnamen erforderlich ist.
TRiG

13

Um Ihre spezifische Frage zu beantworten, gibt es viele Schritte entlang der Ereigniskette zwischen einem Webformular und der Datenbank. Wenn der Nachname Nullfälschlicherweise als NULLWert interpretiert wird, kann das System einen vollständig gültigen Namen als ungültig ablehnen. Dies kann auf der Datenbankebene geschehen, wie von amon erläutert . Übrigens, wenn dies das spezifische Problem ist, dann ist die Datenbank wahrscheinlich auch offen für SQL Injection AKA, den Bobby Tables- Angriff. Ein weiterer Schritt in der Kette, der Probleme verursachen kann, ist der Serialisierungsprozess .

Insgesamt ging es in dem Artikel um ein größeres Problem. Die Welt ist ein großer chaotischer Ort, der nicht immer unseren Annahmen entspricht. Dies wird besonders deutlich, wenn Sie versuchen, Ihre Anwendung zu internationalisieren. Letztendlich müssen wir sicherstellen, dass unsere Anwendungen unsere Daten ordnungsgemäß verarbeiten und verschlüsseln . Es ist Sache des Unternehmens, zu entscheiden, wie viele Ressourcen wir für die Unterstützung immer komplizierterer Randfälle einsetzen. Obwohl ich es voll und ganz unterstütze, inklusiv zu sein, werde ich verstehen, ob das Unternehmen entscheidet, dass "der Künstler, der formal als Prinz bekannt ist", ein Unicode-Zeichen verwenden muss, um seinen Namen in unserer Datenbank darzustellen.


Es ist schwer vorstellbar, dass dies auf die Art der unsicheren Zeichenfolgeninterpolation zurückzuführen ist, die zur SQL-Injection führen kann. Wenn Sie vergessen, Benutzereingaben in einer SQL-Abfrage in Anführungszeichen zu setzen (z. B. " INSERT INTO users (first, last) VALUES($first, $last)auswerten" INSERT INTO users (first, last) VALUES(Jennifer, Null)), werden alle Benutzer , deren Namen keine gültigen SQL-Schlüsselwörter oder Spaltennamen sind, nur Fehler auslösen und auch keine Datensätze einfügen. Die Ursache muss komplexer sein.
Andrew Medico

@ AndrewMedico in deinem Strohmann-Beispiel ja, aber es gibt viele Möglichkeiten, Dinge falsch zu machen. Unterschätze niemals die Macht der <strike> Dummheit <\ strike> Unwissenheit. Das Fazit ist, dass wir keine Ahnung haben, was das eigentliche Problem ist, da wir den fraglichen Code nicht überprüfen können
Erik,

7

Nun, bevor es in die Datenbank eingegeben wird, ist es ein DOM-Element, dann eine JavaScript-Variable, die herumgereicht, validiert und manipuliert wird, dann ein JSON-Wert, dann eine Variable in der Backend-JSON-Bibliothek, die Sie verwenden, und dann eine Variable, die herumgereicht wird. validiert und in Ihrer Backend-Programmiersprache bearbeitet, dann ein Element einer Art DAO, dann Teil einer SQL-Zeichenfolge. Dann, um den Wert wieder herauszuholen, machen Sie alles in umgekehrter Reihenfolge. Das ist eine Menge Orte, an denen Programmierer Fehler machen können, und normalerweise eine Menge, ohne den Vorteil der statischen Eingabe.


2

Höchstwahrscheinlich ist es ein Programmierproblem. Wenn Sie sich diese Antwort hier ansehen, um zu erfahren, wie NULL-Werte übergeben werden, kann dies leicht zu unerwünschtem Verhalten führen, wenn Sie "Mr. Null" sind.

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

Sie können sehen, dass, wenn ein Datenelement als NULL übergeben würde, die Daten als eine Datenbank null in der Datenbank interpoliert würden.

"NULL"! = Database Null

Einige Anwendungsfälle und ähnliches Verhalten ...

Angenommen, der Nachname wurde in der Datenbank als nicht null markiert. Wenn nun Daten eingefügt werden, werden diese als NULL interpretiert und die Einfügung schlägt fehl.

Ein weiterer Fall ist, dass der Nachname in der Datenbank nullwertfähig war. Mr. NULL wird eingefügt und in DBNull.Value umgewandelt, was nicht mit "NULL" identisch ist. Nach dem Einfügen können wir Mr. Null nicht finden, da sein Nachname nicht "NULL" ist, sondern in Wirklichkeit ein Datenbank-Nullwert.

Das wären also 2 Fälle von Problemen. Wie @Amon hervorhebt, gibt es bei Datenbanken selbst keine Probleme mit Nullen, obwohl man verstehen sollte, wie Nullen in jeder RDMS-Instanz behandelt werden, da es Unterschiede zwischen verschiedenen Anbietern gibt.


Msgstr "Sie können sehen, dass wenn ein Datenelement als NULL übergeben würde, die Daten als eine Datenbank null in der Datenbank interpoliert würden." - die verknüpfte SO-Frage / akzeptierte Antwort scheint dies nicht zu zeigen?
MrWhite

2

Ich würde das Problem der schlampigen Programmierung und dem schlechten Design einiger SQL-Implementierungen zuschreiben. "Null" Der Name sollte immer in Anführungszeichen gesetzt und interpretiert werden. Der Datenbankwert null sollte immer ohne Anführungszeichen angegeben werden. Wenn Sie jedoch Ad-hoc-Code schreiben, können Sie leicht in das Paradigma "Alles wird funktionieren" eintauchen und Dinge akzeptieren, die als Zeichenfolge in nicht zitierter Form gelten.

Hinzu kommt, dass andere Datentypen; Zahlen zum Beispiel können und werden in jeder Form akzeptiert, weil die Interpretation eindeutig ist.


Sie meinen damit eine schlechte Implementierung von Anwendungen mit SQL? Keine ernsthafte Implementierung eines RDBMS selbst wäre dafür anfällig (genau wie keine ernsthafte Anwendung!)
underscore_d

0

Grundsätzlich besteht das Problem darin, dass mit dem Begriff "Null" zwei unterschiedliche Datenbankkonzepte angewendet werden, wobei manchmal der Kontext zur Unterscheidung verwendet wird:

  1. Etwas hat keinen bekannten Wert
  2. Es ist bekannt, dass etwas keinen Wert hat

Während der Kontext manchmal ausreicht, um zwischen diesen Konzepten zu unterscheiden, gibt es Zeiten, in denen dies nicht der Fall ist. Wenn beispielsweise ein Datensatz für eine Suchabfrage verwendet wird, sollte es einen Unterschied geben zwischen "Ich möchte jemanden mit dem Namen [was auch immer] ohne Nachnamen" und "Ich möchte jemanden mit dem Vornamen [ was auch immer], aber dessen Nachname ist unbekannt. " Viele Datenbank-Engines tendieren zu der einen oder anderen Bedeutung, aber sie sind nicht alle gleich. Code, der erwartet, dass ein Datenbankmodul in eine Richtung funktioniert, kann fehlerhaft sein, wenn er auf einem anderen Modul ausgeführt wird, das anders ausgeführt wird.


Wenn bekannt ist, dass eine Zeichenfolge keinen Wert hat, sollte der Wert eine leere Zeichenfolge und keine Nullzeichenfolge sein.
Byron Jones

0

Die meisten der vorhandenen Antworten konzentrieren sich auf die Nicht-SQL-Teile einer Anwendung, aber möglicherweise liegt auch ein Problem in SQL vor:

Wenn jemand angewiesen wird, Datensätze herauszufiltern, bei denen der Nachname eines Benutzers nicht verfügbar ist, kann er einen Filter schreiben, wenn er SQL nicht sehr gut versteht WHERE u.lastname != 'NULL'. Aufgrund der Funktionsweise von SQL wird hier überprüft, ob u.lastname IS NOT NULL: alle NULLDatensätze herausgefiltert werden. Alle Nichtaufzeichnungen NULLbleiben erhalten.

Außer natürlich für Aufzeichnungen u.lastname == 'NULL', bei denen möglicherweise während des Tests keine Aufzeichnungen verfügbar waren.

Dies wird umso wahrscheinlicher , wenn die SQL durch eine Art von Rahmen erzeugt wird, wenn dieser Rahmen nicht leicht zugänglich für nicht überprüfen aussetzt NULL-ness mit Parametern, und jemand bemerkt : „Hey, wenn ich in der Zeichenfolge übergebe NULL, es macht genau das was ich will! "

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.