C＃数据库访问：DBNull与null
我们在这里使用自己的ORM，并为所有db表提供强类型包装器。 我们还允许执行弱类型的临时SQL，但这些查询仍然通过相同的类来从数据读取器中获取值。
在调整该类以使用Oracle时，我们遇到了一个有趣的问题。 使用DBNull.Value或null是否更好？ 使用DBNull.Value有什么好处吗？ 使用null似乎更“正确”，因为我们已经将自己从数据库世界中分离出来，但是有一些含义（例如，当值为null时，你不能盲目地使用ToString() ）所以它绝对是我们需要的东西做出有意识的决定。
我发现使用null更好，而不是DB null。
原因是，正如您所说，您将自己与数据库世界分开。
通常，检查引用类型以确保它们不为空是一种很好的做法。 您将检查除DB数据之外的其他内容的null，并且我发现最好保持整个系统的一致性，并使用null，而不是DBNull 。
从长远来看，在架构上我发现它是更好的解决方案。
如果您已经编写了自己的ORM，那么我会说只使用null，因为您可以随意使用它。 我相信DBNull最初只用于解决值类型（int，DateTime等）不能为空的事实，所以不要返回一些像零或DateTime.Min这样的值，这意味着 null（坏，坏） ），他们创建了DBNull来表明这一点。 也许还有更多，但我一直认为这就是原因。 但是，现在我们在C＃3.0中有可空类型，不再需要DBNull。 实际上，LINQ to SQL只是在所有地方使用null。 没问题。 拥抱未来……使用null。 😉
根据我的经验，.NET DataTables和TableAdapter可以更好地与DBNull配合使用。 当强类型时，它还会打开一些特殊方法，例如DataRow.IsFirstNameNull。
我希望我能给你一个比这更好的技术答案，但对我来说，底线是在处理数据库相关对象时使用DBNull，然后在处理对象和.NET相关代码时使用“标准”null。
使用DBNull 。
我们在使用null时鼓励出现某种问题。
如果我没记错，你不能将空值插入字段，只有DBNull。
可能只与甲骨文有关，对不起，我不知道细节了。