DBNull的意义是什么？

在.NET中，存在一个null引用，该引用到处都用于表示对象引用为空，然后是DBNull，该引用由数据库驱动程序（和其他一些驱动程序）用来表示...几乎是同一件事。自然，这会引起很多混乱，必须转换转换例程，等等。

那么，最初的.NET作者为什么决定这样做呢？对我而言，这没有任何意义。他们的文档也没有意义：

DBNull类表示一个不存在的值。例如，在数据库中，表行中的列可能不包含任何数据。即，该列被认为根本不存在，而不仅仅是没有值。DBNull对象表示不存在的列。此外，COM互操作使用DBNull类来区分VT_NULL变体和VT_EMPTY变体，VT_NULL变体表示不存在的值，而VT_EMPTY变体表示未指定的值。

关于“不存在的列”的废话是什么？有一列存在，只是没有特定行的值。如果不存在，则尝试访问特定单元格时会出现异常，而不是DBNull！我可以理解需要区分VT_NULL和VT_EMPTY，但是为什么不COMEmpty上课呢？这将更适合整个.NET框架。

我想念什么吗？谁能说出为什么DBNull发明以及它可以解决什么问题？

关键是，在某些情况下，数据库值为null和.NET Null之间会有区别。

例如。如果使用ExecuteScalar（返回结果集中第一行的第一列），并且返回null，则表示执行的SQL不返回任何值。如果返回DBNull，则表示SQL返回了一个值，该值为NULL。您需要能够分辨出差异。

我不同意这里的趋势。我会继续记录：

我不同意DBNull任何有用的目的。它增加了不必要的混乱，却几乎没有任何价值。

通常会提出null一个参数，它是一个无效的引用，并且DBNull是一个空对象模式。两者都不是真的。例如：

int? x = null;

这不是“无效的参考”；这是一个null价值。确实null意味着您想要表达的意思，坦率地说，使用可能的值绝对没有问题null（实际上，即使在SQL中，我们也需要正确使用null-这里没有任何变化）。同样，“空对象模式”仅在您实际上将其视为OOP术语中的对象时才有意义，但是如果我们的值可以是“我们的值或DBNull”，那么它必须是object，所以我们不能做任何有用的事情。

坏事太多了DBNull：

• 它迫使您使用object，因为只能object持有DBNull 或其他值
• “可以是一个值或DBNull”与“可以是一个值或null”之间没有真正的区别
• 它源自1.1（pre-nullable-types）的说法毫无意义；我们可以null在1.1中很好地使用
• 大多数API具有“是否为null？” 方法，例如-DBDataReader.IsDBNull或DataRow.IsNull实际上都不要求DBNull使用API
• DBNull在无效销售方面失败；value ?? defaultValue如果值是DBNull
• DBNull.Value 不能在可选参数中使用，因为它不是常量
• 的运行时语义DBNull与的语义相同null；特别是DBNull实际上等于DBNull-因此它不能代表SQL语义
• 由于过度使用，通常会强制将值类型值装箱 object
• 如果您需要测试DBNull，则可能还需要测试null
• 它会给诸如命令参数之类的问题带来巨大的问题，它具有非常愚蠢的行为，即如果某个参数具有null值，则不会发送...好吧，这是一个主意：如果您不希望发送参数，则不要将其添加到参数集合
• 每一个ORM我能想到的作品完全良好，没有任何需要或使用的DBNull，聊到ADO.NET代码时，除非额外的滋扰

唯一的甚至是远程我有说服力的论据曾经看到来证明存在这样的值的是DataTable，传递价值，以创建一个新的行时; anull表示“使用默认值”，aDBNull明确为null-坦率地说，此API可能对此情况进行了特定处理-DataRow.DefaultValue例如，虚构方法要比引入DBNull.Value无故感染大量代码的a更好。

同样，ExecuteScalar情况是……充其量是微不足道的。如果执行标量方法，则预期会得到结果。在没有行的情况下，返回null看起来并不可怕。如果您绝对需要在“无行”和“返回一个空值”之间进行歧义，则可以使用阅读器API。

这艘船已经航行很久了，修理它为时已晚。但！请不要不认为所有人都认为这是一个“明显”的事情。许多开发人员都没有看到对BCL这个奇怪的皱纹值。

我实际上想知道所有这些是否源于两件事：

• 必须使用单词Nothing代替VB中涉及“空”的单词
• 能够为我们if(value is DBNull)提供“看起来像SQL”的语法，而不是让人讨厌的语法if(value==null)

概要：

仅当有一个真实的示例需要区分3种不同情况时，才具有3个选项（null，DBNull或实际值）才有用。我还没有看到需要代表两个不同的“空”状态的情况，因此DBNull鉴于null已经存在并且具有更好的语言和运行时支持，因此完全是多余的。

DbNull表示没有内容的盒子；null表示该框不存在。

您使用DBNull丢失数据。.NET语言中的Null表示没有对象/变量的指针。

DBNull缺少数据：http : //msdn.microsoft.com/zh-cn/library/system.dbnull.value.aspx

数据丢失对统计的影响：

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

CLR null和DBNull之间有一些区别。首先，关系数据库中的null具有不同的“等于”语义：null不等于null。CLR null IS等于null。

但是我怀疑主要原因是与参数默认值在SQL Server中的工作方式以及提供程序的实现有关。

若要查看区别，请创建一个具有默认值的参数的过程：

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

结构良好的DAL代码应将命令的创建与使用分开（以使多次使用同一命令成为可能，例如，有效地多次调用存储过程）。编写一个返回代表上述过程的SqlCommand的方法：

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

如果现在在不设置@s参数的情况下调用该命令，或者将其值设置为（CLR）null，则它将使用默认值“ hello”。另一方面，如果将参数值设置为DBNull.Value，它将使用该值并回显DbNull.Value。

由于使用CLR空值或数据库空值作为参数值会有两种不同的结果，因此不能仅用其中一种来表示两种情况。如果CLR null是唯一的值，则必须像DBNull.Value那样工作。向提供者指示“我要使用默认值”的一种方式可能是根本不声明参数（具有默认值的参数当然可以描述为“可选参数”），但是在在缓存和重用命令对象的情况下，这确实会导致删除和重新添加参数。

我不确定DBNull是否是个好主意，但很多人不知道我在这里提到的内容，因此我认为值得一提。

要回答您的问题，您必须考虑为什么DBNull甚至存在？

在狭窄的用例中，DBNull是必需的。否则，事实并非如此。大多数人从不需要DBNull。我绝对不允许将它们输入我设计的数据存储中。我总是有一个值，因此我的数据永远不会是“ <null>”，我总是选择一个有意义的类型“默认值”，而且我也不必这样做，这荒唐的重复检查代码中的所有内容两次，一次是对象null，再一次是因为DBNull是在我将对象转换为实际数据类型（例如Int等）之前。

在某些情况下，可能需要DBNull ...如果您使用某些SQL统计函数（例如，中位数，平均值）..它们特别对待DBNull ..请查看这些文档..某些函数不包含DBNull统计的总计数中...例如：（87总和/ 127总）与（87总和/ 117总）..区别在于那些列值中的10个是DBNull ...您会看到这将会改变统计结果。

我无需使用DBNull设计数据库。如果我需要统计结果，我会为该项目明确发明或添加一列，例如“ UserDidProvideValue”，因为该项目不存在（例如，我的总数为117，即为标记字段的总和） UserDidProvideValue = true）...哈哈哈哈-在我下一世作为宇宙的统治者时-DBNull将再也无法逃脱SQL领域了...整个编程世界现在担负着检查所有事情的重担...何时您是否曾经有一个移动应用程序或台式机应用程序或网站需要一个“空”整数？-从来没有...