使用 DBNull 或 null 插入/更新数据?
修改 SQL Server 数据库中的数据时,可以使用 System.DBNull.Value
或 null
来表示 NULL
值。这两个方法都可以工作,并将正确的值设置为NULL
。
我的问题是 - 首选其中哪一个,为什么?在某些情况下是否应该使用其中一个来代替另一个?
When modifying data in a SQL Server database you can use either System.DBNull.Value
or null
to represent a NULL
value. Both of these will work and will set the proper value to NULL
.
My question is - which of these is preferred, and why? Are there certain cases where one should be used in place of the other?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
来自 System.DBNull.Value != null ,并通过测试此代码:
我们可以看到 CLR 并没有以相同的方式对待它们。从数据库检索数据时,我们需要检查
DBNull.Value
而不是null
引用。尽管我们使用
INSERT
或UPDATE
数据并不重要,但我倾向于坚持使用DBNull.Value
来保证数据访问的一致性代码。问题C# Database Access: DBNull vs null< 中有多种其他意见/a>
From System.DBNull.Value != null, and by testing this code:
We can see that the CLR doesn't treat them the same way. When retrieving data from a database we need to check for
DBNull.Value
and not anull
reference.Although it doesn't matter which we use to
INSERT
orUPDATE
data, I would tend to stick withDBNull.Value
for consistency through data access code.There are a variety of other opinions in the question C# Database Access: DBNull vs null
DBNull 代表一种变体,而不是特定于类型的。在一般情况下,我预计只要有一个需要强类型数据集并且必须将 DBNull 转换为“typed-NULL”的构造,性能都会受到影响。
DBNull is representative of a variant and is not type-specific. In a general context, I would expect a performance hit anywhere you have a construct that expects a strongly-typed dataset and has to convert DBNull to a "typed-NULL".