所以我正在使用一个包含许多默认值的表:
CREATE TABLE BLAH.BLAH
(
...
A NUMBER(19) DEFAULT 0 NOT NULL,
B VARCHAR2(50) DEFAULT ' ' NOT NULL,
C TIMESTAMP(6) DEFAULT '01-JAN-1900' NOT NULL,
...
)
我只是想知道是否有任何逻辑上的目的是将这种类似null的默认值设置为更好(在我看来)设置为实际NULL的列。
编辑:我对varchar2默认情况感到厌烦。其他的更合理,更容易使用。当许多代码涉及修剪时,这只是一种痛苦;当我期待一个空格时,我得到了NULL。
答案 0 :(得分:3)
如果您理解空值并且习惯于处理它们,那就没有多大意义了。
在它自己的疯狂世界中它有某种逻辑,因为如果你从来没有空值,那么值更容易映射到编程语言(所有都有整数类型,但并非所有都具有可为空的整数类型)并且比较' “等同”更容易(0 = 0
,但null = null
}并非如此。但需要权衡的是,您必须在程序和任何SQL查询中使用样板检查来处理这些神奇的默认值。
这也可能是由于某些误用,以货物为基础的“编码标准”禁止在数据库中使用可空列,并且需要具有某种“未知”值。
确实,在SQL中(以及在一般的关系模型中)包含空值会增加复杂性并且一直存在争议。 (我不打算在这里给出引用的完整纲要或争论任何特定的观点;我只是说这些论点存在。)有人建议如果你需要可以为空的列,你应该修改你的数据模型到完全正常化; Codd认为单个零点是不够的,应该有单独的“缺失”和“不适用”。但我确信没有人提倡摆脱null
建议用虚假的0
或1900-01-01
代替它......所以再一次可能是一个误解和误用的情况关于不使用空值的一些设计规则。
这种扭曲的思维过程很常见 - 我继承了一个数据库,其中规则禁止可以为空的列(并且有依赖于它的API)但字符串'?'用来代替。事实上,有意思是'?'并且'/'代表'缺失'和'不适用' - 遵循Codd的建议 - 但你可以猜测现实世界的数据或代码观察到了多少区别以及它在实践中的用处。
答案 1 :(得分:1)
有原因吗?在某些开发组中可能存在。当你说:
select *
from blah
where timestamp <> date '2015-01-01'
您可能希望查询返回默认值。如果默认值为NULL
,则查询将不会返回它们。如果默认值是过去的日期,那么它将会。
同样,您可能不希望使用大量or X is null
来混淆代码。这不仅仅是一个美学问题。 or
和where
中on
的存在为代码错误提供了机会(由于缺少括号),并且可能会使优化程序混淆。
我不说使用此类默认值是最佳做法。 NULL
是SQL语言的重要组成部分,任何编写生产代码的人都应该知道如何处理它。但是,你提到的风格有充分的理由。