Was ist der Sinn von DBNull?

In .NET da ist der null Referenz, das wird überall verwendet, um anzuzeigen, dass eine Referenz auf ein Objekt leer ist, und dann gibt es die DBNull zu, die von Datenbank-Treiber (und einige andere) zu bezeichnen... ziemlich viel die gleiche Sache. Natürlich, das schafft eine Menge Verwirrung und Konvertierungsroutinen zu aufgewühlt, etc.

Also, warum ist das original .NET-Autoren entscheiden? Für mich macht es keinen Sinn. Ihre Dokumentation macht keinen Sinn, entweder:

Der DBNull-Klasse repräsentiert einen nicht vorhandenen Wert. In einer Datenbank beispielsweise eine Spalte in einer Zeile einer Tabelle kann keine Daten enthalten, löschen. Das heißt, die Spalte ist als nicht vorhanden, statt nur nicht mit einem Wert. Ein DBNull-Objekt repräsentiert die nicht vorhandene Spalte. Darüber hinaus werden die COM-interop, verwendet die Klasse DBNull zu unterscheiden zwischen einem VT_NULL Variante, die zeigt einen nicht vorhandenen Wert, und ein VT_EMPTY Variante, die zeigt an, das ein unbekannter Wert.

Was dieser Mist über eine "Spalte nicht vorhanden"? Eine Spalte vorhanden ist, ist es einfach nicht Wert für die jeweilige Zeile. Wenn es das nicht gibt, ich würde eine Ausnahme ausgelöst werden, versuchen auf die spezifische Zelle, nicht eine DBNull! Ich kann verstehen, die Notwendigkeit zu unterscheiden zwischen VT_NULL und VT_EMPTYaber warum dann nicht eine COMEmpty statt Klasse? Das wäre ein viel ordentlicher passen in das ganze .NET framework.

Bin ich etwas fehlt? Kann jemand Aufschluss geben, warum DBNull erfunden wurde und welche Probleme hilft es zu lösen?

InformationsquelleAutor der Frage Vilx- | 2010-12-20

  1. 42

    Der Punkt ist, dass in bestimmten Situationen gibt es einen Unterschied zwischen einer Datenbank mit dem Wert null und einem .NETTO-Null.

    Zum Beispiel. Wenn Sie mit ExecuteScalar (das gibt die erste Spalte der ersten Zeile in der Ergebnismenge) und Sie bekommen eine null zurück, das bedeutet, dass die SQL ausgeführt, nicht wieder alle Werte. Wenn Sie DBNull zurück, es bedeutet, dass ein Wert zurückgegeben wurde, die von der SQL-und es war NULL. Sie müssen in der Lage sein, den Unterschied zu erkennen.

    InformationsquelleAutor der Antwort Colin Mackay

  2. 157

    Werde ich nicht mit den trend hier. Ich geh auf record:

    Ich bin nicht einverstanden, dass DBNull dient keinem sinnvollen Zweck, es fügt unnötige Verwirrung, und trägt praktisch keinen Wert.

    Das argument wird oft vorgebracht, dass null ist eine ungültige Referenz, und dass DBNull ist ein null-Objekt-pattern; weder wahr ist. Zum Beispiel:

    int? x = null;

    dies ist nicht eine "ungültige Referenz"; es ist ein null Wert. In der Tat null bedeutet das, was immer du willst, das es bedeutet, und ehrlich gesagt, ich habe absolut kein problem, die Arbeit mit Werten, die möglicherweise null (ja, auch in SQL müssen wir richtig arbeiten mit null - ändert sich hier nichts). Ebenso ist die "null-Objekt-pattern" macht nur dann Sinn, wenn Sie tatsächlich behandeln Sie es als ein Objekt in OOP-Hinsicht, aber wenn wir einen Wert haben, kann "unseren Wert, oder ein DBNull" dann muss es objectso können wir nicht tun, etwas sinnvolles mit ihm.

    Es gibt so viele schlechte Dinge mit DBNull:

    • es zwingt Sie, mit zu arbeiten objectda nur object halten kann DBNull oder anderen Wert
    • es gibt keinen wirklichen Unterschied zwischen "könnte ein Wert sein oder DBNull" vs "kann einen Wert oder null"
    • dem argument, es ergibt sich aus 1.1 (pre-nullable-Typen) ist sinnlos; wir könnten null perfekt in 1.1
    • die meisten APIs "ist es null?" Methoden, wie zum Beispiel DBDataReader.IsDBNull oder DataRow.IsNull - weder die tatsächlich benötigen DBNull zu existieren in Bezug auf die API
    • DBNull fehl in Bezug auf die null-coalescing; value ?? defaultValue funktioniert nicht, wenn der Wert DBNull
    • DBNull.Value können nicht verwendet werden, optionale Parameter, da es nicht eine Konstante
    • die Laufzeit-Semantik von DBNull identisch sind, um die Semantik von null; insbesondere DBNull eigentlich gleich DBNull - so ist es nicht den job machen, der Vertretung der SQL semantische
    • es oft Kräfte Wert-Typ werden die Werte des boxed da es über-verwendet object
    • wenn Sie brauchen, um zu testen, für DBNullkönnte man genauso gut getestet haben für nur null
    • verursacht es große Probleme für Dinge wie command-Parameter, mit einer sehr albern Verhalten, wenn für einen parameter ein null Wert ist es nicht verschickt... naja, hier ist eine Idee: wenn Sie nicht möchten, dass ein parameter gesendet - nicht fügen Sie Sie der parameters-Auflistung
    • jeder ORM ich denken kann, funktioniert perfekt auch ohne alle müssen, oder verwenden Sie von DBNullaußer als ein zusätzliches ärgernis, wenn im Gespräch mit der ADO.NET code

    Nur auch nur im entferntesten überzeugende argument, das ich habe immer gesehen zu rechtfertigen, die Existenz solch ein Wert ist in DataTablewenn man die Werte zum erstellen einer neuen Zeile; ein null bedeutet "verwenden Sie den Standard", ein DBNull ist explizit eine null - ehrlich diese API hatte, konnte eine spezifische Behandlung für diese Fall - eine imaginäre DataRow.DefaultValue zum Beispiel wäre viel besser, als die Einführung einer DBNull.Value infiziert weite Teile des Codes für keinen Grund.

    Gleichermaßen, die ExecuteScalar Szenario ist... zu schwach am besten, wenn Sie ausführen, eine Skalare Methode, Sie erwarten Ergebnis. In dem Szenario, wo es keine Zeilen gibt, die Rückgabe null scheint nicht zu schrecklich. Wenn Sie unbedingt brauchen, um keine Verwechslungen zwischen "keine " Zeilen" und "eine einzige null zurückgegeben", gibt ' s die reader-API.

    Diesem Schiff gesegelt ist lange her, und es ist viel viel zu spät, um es zu beheben. Aber! Bitte nicht glaube, dass jeder zustimmt, dass dies eine "offensichtliche" Sache. Viele Entwickler tun nicht siehe Wert in diese seltsame Falten auf die BCL.

    Ich tatsächlich Fragen, ob all dies ergibt sich aus zwei Dingen:

    • dass das Wort Nothing statt etwas mit "null" in VB
    • können Sie uns if(value is DBNull) syntax "sieht genauso aus wie SQL", anstatt die ach-so-schwierig if(value==null)

    Zusammenfassung:

    Haben 3 Optionen ( null , DBNull oder ein Aktueller Wert) ist nur dann sinnvoll, wenn es ein echtes Beispiel, wo Sie brauchen, um keine Verwechslungen zwischen 3 verschiedenen Fällen. Ich habe noch um zu sehen, eine Gelegenheit, wo muss ich repräsentieren zwei verschiedene "null" - Staaten, also DBNull ist völlig redundant, da null existiert bereits und hat viel bessere Sprache und die runtime-support.

    InformationsquelleAutor der Antwort Marc Gravell

  3. 12

    DbNull stellt eine box ohne Inhalt; null zeigt die nicht-Existenz der box.

    InformationsquelleAutor der Antwort Rikalous

  4. 1

    Verwenden Sie DBNull für fehlende Daten. Null in der .NET-Sprache bedeutet, dass es keine Zeiger für ein Objekt/variable.

    DBNull fehlende Daten: http://msdn.microsoft.com/en-us/library/system.dbnull.value.aspx

    Den Auswirkungen von fehlenden Daten auf die Statistik:

    http://en.wikipedia.org/wiki/Missing_values

    InformationsquelleAutor der Antwort jvdbogae

  5. 0

    Gibt es einige Unterschiede zwischen einem CLR null und DBNull. Zuerst null in relationalen Datenbanken hat verschiedene "gleich" - Semantik: null ist nicht gleich null. CLR null IST gleich null.

    Aber ich vermute, der Hauptgrund ist, das zu tun, mit der Art-parameter default-Werte in SQL server und der Umsetzung der Anbieter.

    Den Unterschied zu sehen, erstellen Sie eine Prozedur mit einem parameter, der einen Standardwert hat:

    CREATE PROC [Echo] @s varchar(MAX) = 'hello'
AS
    SELECT @s [Echo]

    Gut strukturierte DAL code zu trennen, Befehl Schöpfung aus einer Verwendung zu aktivieren, verwenden Sie den gleichen Befehl viele Male, zum Beispiel zum aufrufen einer gespeicherten Prozedur viele Male effizient). Schreiben Sie eine Methode, die zurückgibt, ein SqlCommand-Objekt repräsentiert die oben beschriebene Prozedur:

    SqlCommand GetEchoProc()
{
    var cmd = new SqlCommand("Echo");
    cmd.Parameters.Add("@s", SqlDbType.VarChar);
    return cmd;
}

    Wenn Sie nun den Befehl aufzurufen, ohne die @s-parameter, oder setzen Sie seinen Wert auf (CLR) null wird, wird der default-Wert 'hello'. Wenn Sie auf der anderen Seite stellen Sie den parameter Wert DBNull.Wert, es verwendet wird, und "echo" DbNull.Wert.

    Da gibt es zwei verschiedene Ergebnisse mit CLR null oder die Datenbank null als Parameterwert kann, kann Sie nicht repräsentieren beiden Fällen mit nur einer von Ihnen. Wenn CLR null war die einzige zu sein, es müsste so funktionieren, wie DBNull.Wert heute. Ein Weg, um anzuzeigen, dass der Anbieter "ich möchte, dass die Verwendung der default-Wert" könnte dann nicht erklären, die parameter (ein parameter mit einem default-Wert natürlich macht Sinn um zu beschreiben, wie ein "optionaler parameter"), aber in einem Szenario, in dem das command-Objekt wird zwischengespeichert und wiederverwendet werden, dies führt zu entfernen und neu-hinzufügen des Parameters.

    Ich bin mir nicht sicher, ob ich denke, dass DBNull eine gute Idee war oder nicht, aber eine Menge Leute sind sich nicht bewusst, die Dinge, die ich erwähnt habe hier, so habe ich es erwähnenswert.

    InformationsquelleAutor der Antwort The Dag

Schreibe einen Kommentar