提问人：David Wengier 提问时间：8/16/2008 最后编辑：burning_LEGIONDavid Wengier 更新时间：8/12/2012 访问量：15233
C# 数据库访问：DBNull 与 null
C# Database Access: DBNull vs null
问：
我们在这里使用自己的 ORM，并为所有 db 表提供强类型包装器。我们还允许执行弱类型的即席 SQL，但这些查询仍然通过相同的类从数据读取器中获取值。
在调整该类以使用 Oracle 时，我们遇到了一个有趣的问题。使用 DBNull.Value 还是 null 更好？使用 DBNull.Value 有什么好处吗？使用 null 似乎更“正确”，因为我们已经将自己与数据库世界分开了，但也有影响（例如，当一个值为 null 时，你不能盲目地这样做），所以它绝对是我们需要做出有意识的决定。ToString()
答：
3赞
Dillie-O
8/16/2008
#1
根据我的经验，.NET DataTables 和 TableAdapter 可以更好地与 DBNull 配合使用。它还会在强类型时打开一些特殊方法，例如 DataRow.IsFirstNameNull。
我希望我能给你一个比这更好的技术答案，但对我来说，底线是在处理数据库相关对象时使用 DBNull，然后在处理对象和 .NET 相关代码时使用“标准”null。
1赞
John Smithers
8/16/2008
#2
用。
我们在使用 null 时遇到了一些问题。
如果我没记错的话，您不能将空值插入到字段中，只能插入 DBNull。
可能只与Oracle有关，对不起，我不知道细节了。DBNull
15赞
Dan Herbert
8/16/2008
#3
我发现最好使用 null 而不是 DB null。
原因是，正如你所说，你正在将自己与DB世界分开。
通常，最好检查引用类型，以确保它们无论如何都不为 null。您将检查数据库数据以外的内容是否为 null，我发现最好在整个系统中保持一致性，并使用 null，而不是 .DBNull
从长远来看，从架构上讲，我发现它是更好的解决方案。
7赞
jeremcc
8/16/2008
#4
如果你已经编写了自己的 ORM，那么我会说只使用 null，因为你可以随心所欲地使用它。我相信 DBNull 最初只是为了解决值类型（int、DateTime 等）不能为 null 的事实，因此他们没有返回一些值，例如 zero 或 DateTime.Min，这意味着 null（bad，bad），他们创建了 DBNull 来指示这一点。也许还有更多，但我一直认为这就是原因。但是，现在我们在 C# 3.0 中拥有可为 null 的类型，因此不再需要 DBNull。事实上，LINQ to SQL 只是到处使用 null。完全没问题。拥抱未来...使用 null。;-)
评论
0赞
fostandy
11/29/2009
我认为 DBNull 仍然有一些用途。至少使用 sqlite，我可以测试 ExecuteScalar（） 返回的值是否显式存储在数据库中。 考虑表 foo（a int， b int）;具有单行 （1， null） 。如果我们要对命令“SELECT b FROM foo WHERE A = 1”执行标量，它将返回 DBNull.Value（该行存在存储 null）。如果我在“SELECT b FROM foo WHERE A = 2”上调用 ExecuteScalar，它将返回 null（不存在此类行）。据推测，您可以使用 DataReader 获得相同的结果，但我确实很欣赏它的便利性。
0赞
jeremcc
12/5/2009
有趣。在使用 ORM 进行数据库访问时，我通常不会在代码中显式使用 ExecuteScalar。我通常最终会检索完整的实体对象，并以这种方式查看它们的值。因此，如果实体本身为 null，那是一回事，如果值为 null，则是另一回事。只是不同的方法。我承认，如果您只需要一个值，ExecuteScalar 会更有效率。
评论