C# 数据库访问：DBNull 与 null
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/12836/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
C# Database Access: DBNull vs null
提问by David Wengier
We have our own ORM we use here, and provide strongly typed wrappers for all of our db tables. We also allow weakly typed ad-hoc SQL to be executed, but these queries still go through the same class for getting values out of a data reader.
我们在这里使用我们自己的 ORM，并为我们所有的 db 表提供强类型包装器。我们还允许执行弱类型的即席 SQL，但这些查询仍然通过同一个类从数据读取器中获取值。
In tweaking that class to work with Oracle, we've come across an interesting question. Is it better to use DBNull.Value, or null? Are there any benefits to using DBNull.Value? It seems more "correct" to use null, since we've separated ourselves from the DB world, but there are implications (you can't just blindly ToString()when a value is null for example) so its definitely something we need to make a conscious decision about.
在调整该类以使用 Oracle 时，我们遇到了一个有趣的问题。使用 DBNull.Value 还是 null 更好？使用 DBNull.Value 有什么好处吗？使用 null 似乎更“正确”，因为我们已经将自己与数据库世界分开了，但是有一些含义（ToString()例如，当值为 null 时，您不能盲目地使用），因此这绝对是我们需要意识到的关于的决定。
采纳答案by Dan Herbert
I find it better to use null, instead of DB null.
我发现使用 null 而不是 DB null 更好。
The reason is because, as you said, you're separating yourself from the DB world.
原因是，正如您所说，您将自己与数据库世界分开。
It is generally good practice to check reference types to ensure they aren't null anyway. You're going to be checking for null for things other than DB data, and I find it is best to keep consistency across the system, and use null, not DBNull.
检查引用类型以确保它们无论如何都不为空通常是一种很好的做法。您将检查数据库数据以外的内容是否为 null，我发现最好保持整个系统的一致性，并使用 null，而不是DBNull.
In the long run, architecturally I find it to be the better solution.
从长远来看，在架构上我发现它是更好的解决方案。
回答by Dillie-O
From the experience I've had, the .NET DataTables and TableAdapters work better with DBNull. It also opens up a few special methods when strongly typed, such as DataRow.IsFirstNameNull when in place.
根据我的经验，.NET DataTables 和 TableAdapters 与 DBNull 一起工作得更好。它还在强类型时打开了一些特殊方法，例如 DataRow.IsFirstNameNull 时。
I wish I could give you a better technical answer than that, but for me the bottom line is use DBNull when working with the database related objects and then use a "standard" null when I'm dealing with objects and .NET related code.
我希望我能给你一个比这更好的技术答案，但对我来说，底线是在处理数据库相关对象时使用 DBNull，然后在处理对象和 .NET 相关代码时使用“标准”空值。
回答by John Smithers
Use DBNull.
We encouintered some sort of problems when using null.
If I recall correctly you cannot INSERT a null value to a field, only DBNull.
Could be Oracle related only, sorry, I do not know the details anymore.
使用DBNull.
我们在使用 null 时遇到了一些问题。
如果我没记错的话，您不能向字段插入空值，只能插入 DBNull。
可能只是 Oracle 相关的，抱歉，我不知道详细信息了。
回答by jeremcc
If you've written your own ORM, then I would say just use null, since you can use it however you want. I believe DBNull was originally used only to get around the fact that value types (int, DateTime, etc.) could not benull, so rather than return some value like zero or DateTime.Min, which would implya null (bad, bad), they created DBNull to indicate this. Maybe there was more to it, but I always assumed that was the reason. However, now that we have nullable types in C# 3.0, DBNull is no longer necessary. In fact, LINQ to SQL just uses null all over the place. No problem at all. Embrace the future... use null. ;-)
如果您已经编写了自己的 ORM，那么我会说只使用 null，因为您可以随心所欲地使用它。我相信 DBNull 最初仅用于解决值类型（int、DateTime 等）不能为null的事实，因此与其返回一些值，如零或 DateTime.Min，这意味着null（坏的，坏的） )，他们创建了 DBNull 来表明这一点。也许还有更多原因，但我一直认为这就是原因。但是，现在我们在 C# 3.0 中有可空类型，DBNull 不再是必需的。事实上，LINQ to SQL 只是到处使用 null。完全没有问题。拥抱未来......使用null。;-)
