sql查询null - sql非空




SQL:使用NULL值与默认值 (9)

在SQL中使用NULL值而不是默认值有什么优缺点

PS。 这里已经提出了许多类似的问题,但没有人回答我的问题。


数据库中的NULL值是占用一个存储字节的系统值,表示不存在值而不是空格或零或任何其他默认值。 包含NULL值的数据库中的字段表示此单元格的内容在查看时未知。 允许NULL值的列也允许插入行,该列中根本没有值。 使用NULL值而不是默认值有几个优点和缺点:

优点

NULL值没有数据类型,因此可以插入任何数据结构和任何数据库列。 另一方面,默认值需要指定其数据类型,并且一列中的默认值在另一列中可能看起来相同,但它可能是不同的类型。

NULL通常用于模式中,其中值是可选的。 这是一种省略未知字段数据输入的便捷方法,而无需实现其他规则,例如在整数字段中存储负值以表示省略的数据。

由于NULL值仅占用1位内存空间,因此在优化数据库时它们可能很有用。 使用这些值比默认值更有效,例如字符的8位和整数的16位。

虽然您的系统要求可能会随着时间的推移而改变,并且默认值类型与它们一起使用,但NULL值始终为NULL,因此无需更新数据类型。

为表格模式分配Not Null也可以帮助进行表格验证,因为具有Not Null条件的列将需要插入值。 默认值没有这些功能。

缺点

NULL值很容易与空字符串混淆,空字符串在选中时会向用户返回空值。 从这个意义上讲,默认值不那么容易混淆,并且是更安全的选项,除非将默认值设置为空字符串。

如果数据库中允许NULL值,它们可能会使设计人员有一些额外的时间和工作,因为它们会使数据库逻辑变得更复杂,尤其是当存在大量与空值的比较时。

来源: 赞成和缺点



Nulls永远不会在DB2 for OS / 390和z / OS中节省存储空间。 每个可空列都需要一个额外的存储空间用于空指示符。 因此,可以为空的CHAR(10)列每行需要11个字节的存储空间 - 数据为10个,空指示符为1个字节。 无论列是否设置为null,都是这种情况。

DB2 for Linux,Unix和Windows有一个压缩选项,允许将列设置为null以节省空间。 使用此选项会导致DB2从列中设置为null的行中消除未使用的空间。 但是,此选项在大型机上不可用。

REF: http://www.craigsmullins.com/bp7.htmhttp://www.craigsmullins.com/bp7.htm

因此,DB2 Z / OS的最佳建模实践是使用“NOT NULL WITH DEFAULT”作为所有列的标准。 我知道的一些主要商店也是如此。 通过消除对NULL INDICATOR使用额外字节的需要,使得程序员的生活更加轻松,无需处理Null指示符并实际节省存储空间。


Null值和默认值是用于不同目的的不同内容。 如果你试图通过给所有东西一个默认值来避免使用null ,那么这是一个糟糕的做法,我将解释。

Null意味着我们不知道价值是什么或将是什么。 例如,假设您有一个enddate字段。 您不知道正在记录的进程何时结束,因此null是唯一合适的值; 使用某些伪日期的默认值将来会导致编程和处理null s一样麻烦,并且更有可能在我的经验中创建返回错误结果的问题。

现在,有时我们可能知道插入记录的人不应该是什么值。 例如,如果您有一个date inserted字段,那么拥有当前日期的默认值并且不希望用户填写此字段是合适的。您可能实际上有更好的信息用于此字段。

有时,这是一个判断调用,取决于您必须应用的业务规则。 假设您有一个speaker honoraria领域(这是发言人获得报酬的金额)。 默认值0可能是危险的,因为它可能意味着扬声器被雇用,我们打算不支付任何费用。 也有可能偶尔会有发言者为特定项目捐赠时间(或者是公司员工,因此没有额外付费发言),其中零是正确值,因此您不能使用零作为确定您不知道该演讲者需要付多少钱的价值。 在这种情况下, Null是唯一合适的值,如果有人试图将发言者添加到会议中,则代码应该触发问题。 在不同的情况下,您可能已经知道任何发言者的最低支付额为3000,并且只有经过协商不同费率的发言人才会在honoraria字段中输入数据。 在这种情况下,将默认值设置为3000是合适的。 在另一种情况下,不同的客户端可能具有不同的最小值,因此应该以不同的方式处理默认值(通常通过查找表自动填充数据输入表单上该客户端的最小honoraria值。

因此,我认为最好的规则是将值保留为null如果您在输入数据时真正无法知道该字段的值应该是什么。 使用默认值只有它具有该特定情况的所有时间,并使用其他技术填写值,如果它在不同情况下可能不同。


在数据仓库中,您总是希望使用默认值而不是NULL。

相反,你会有“未知”,“未准备好”,“缺失”等价值

这允许INNER JOIN在Fact和Dimension表上高效执行,因为“一切都有值”


对我来说,它们有点正交。

默认值允许您优雅地发展数据库模式(想想添加列),而无需修改客户端代码。 另外,他们节省了一些打字,但依靠默认值是IMO坏。

空是这样的: null s。 处理三值逻辑时缺少价值和巨大的PITA。


正如一位响应者已经说过,NULL不是一个值。

对任何说“NULL值”的人宣称的任何东西都非常有用,就好像它是一个值。

NULL不等于它自己。 如果x和y都为NULL,则x = y产生false。 如果x和y都是默认值,则x = y得到true。

这种看似非常简单的差异几乎无穷无尽。 而这些后果中的大多数都是诱人的陷阱,让你感到非常糟糕。


空值不是......值!

Null意味着“没有价值”......除了数据库方面,非值变量或字段的一个重要维度是在比较变量时不可能使用'='(或'>','<')。

写一些像(VB):

if myFirstValue = mySecondValue

如果一个或两个变量都是非值,则不会返回True或False。 您将不得不使用“周转”,例如:

if (isnull(myFirstValue) and isNull(mySecondValue)) or myFirstValue = mySecondValue

在这种情况下使用的“通常”代码是

if Nz(myFirstValue) = Nz(mySecondValue, defaultValue)

不严格正确,因为非值变量将被视为与'defaultValue'值(通常为零长度字符串)“相等”。

尽管存在这种令人不快的行为,但永远不要永远不要将默认值打开到零长度字符串(或'0')而没有有价值的理由,并且在代码中简化值比较并不是一个有价值的理由。


我不知道为什么你甚至试图将这些与案例进行比较。 null表示某些列为空/没有值,而当我们不在查询中直接设置时,默认值会为列提供一些值。

也许一些例子将是更好的解释。 假设我们是member表。 每个成员都有一个ID和用户名。 可选他可能有一个电子邮件地址(但他没有)。 此外,每个成员都有一个postCount列(每次用户编写帖子时都会增加)。 因此,电子邮件列可以具有null值(因为电子邮件是可选的),而postCount列是非NOT NULL但具有默认值0 (因为当我们创建新成员时他没有任何帖子)。





database-design