CSDN博客

img ccat

SQL Story摘录(七)————触摸NULL值

发表于2002/6/19 9:00:00  1550人阅读

前面的文章中,我们初步见识了NULL这个不可思议的小东西。今天,我尽可能详细的介绍一下它。依照惯例,这是一次尽量浅显但并不严谨的讨论,甚至可能内容也不那么严肃。我的目的在于帮助读者更轻松地工作,并且有兴趣对数据库进一步的学习。从另一方面讲,我相信自己论点中的错误,肯定会有其他人也在犯,所以请发现不妥的朋友一定要公开指出。这样,才有助于我和我的读者朋友们进步。衷心感谢每一个提出批评和指正的朋友,特别是公开提出批评和指正的朋友们。特别感谢sunshine19,专程发来E-mail,指出了《SQL Story》 的种种不足,并提出了宝贵意见。我期望他继续关心这个专题,并期望他为我们带来优秀的作品。

无可回避的不存在

例:双人房间。

假设某个学校,它的单身职工公寓中,每个房间有两个床位。这样做有很多好处,比如安全,都是半大不小的年轻人,不管男孩女孩,有个伴一起住总让人放心些,互相也有个照应;如果有谁结了婚,由于每个房间最多住两个人,还可以比较容易地找出一间,先给他们安个家,慢慢等着分房。这些事当然不要我们程序员多操心(除非我们就住在里面)。现在要关心的是,有人做了一个公寓管理数据库。其中的房间管理表这样子设计:

CREATE TABLE ROOMS(

ROOMID CHAR(5),

MASTERID CHAR(10) ,

SECONDID CHAR(10),

CONSTRAINT PK_ROOM PRIMARY KEY(ROOMID),

CONSTRAINT FK_MASTER FOREIGN KEY (MASTERID) REFERENCES LIVERS(ID),

CONSTRAINT FK_SECOND FOREIGN KEY (SECONDID) REFERENCES LIVERS(ID)

)

简单介绍一下,管理员为了方便管理(比如收个水电费什么的),要求每一个住人的房间有一个房主;两个人更详细的信息保存在了 LIVERS表中,所以我们看到有两个外键约束。当然,这个设计并非无懈可击,不过它也自有它的理由,在这里我们先不讨论了。

这里要关注的是,房客少于两个人的房间,我们该在空出来的地方填什么?有一个方法,就是填入一个空字符串,可这样一来,就等于我们默认了存在一个ID号为空字符串的住户存在。因为空字符串也是字符串嘛。两个外键约束也说明了这一点。事实上,在类似这样的设计中,我就见过一些例子,其作者为了避免无可引用的情况,凭空造出一个不存在的信息,做为数据库结构的一部分。具体到这个例子,可能会有人真的用一个空字符串或写一个“NONE”什么的,写在LIVERS表中,表示没有人居住。通常这会引起很多问题,比如我们可能要加一个约束,使得一个人不能出现在ROOMS表中两次。可现在这个虚拟出来表示没有人的房客怎么办?可有很多位置都没有人啊,比如只要有一个空房,就会在这一条记录上有两个“NONE”!在更离奇(但在某些应用中绝非不可能)的情况下,有一个房客,他的ID就是“NONE”,如何??而且如果极端情况下,房客全搬出去了,怎么办?想要“DELET FROM LIVERS”都不行,“NONE” 可删不掉啊。当你工作在这样一个数据库中,得时时提醒自己不要得罪了这个不存在的家伙。要记住,他没有性别,所以男女职工的房间他都要住;别人一个人只能睡一张床,他却可以要所有空闲的;别人都搬出去后,他老人家一个人占了所有的房间,我们的法律规章对他全没有意义。这种特殊值给我们带来的最大问题,就是把信息和数据库结构搅在了一起。也就是说,关系和关系的模式混为一谈了。如果一个数据库中有上几个这种表,谁都会疯的。

这就是NULL的意义,当你把一个数据定义为NULL时,就等于告诉系统,这个数据不存在,或未知。不要管它了,它的内容没有意义(当然,这本身也是一种意义)。在房间中有一个NULL,只表示没有人,而不会被认为是一个叫“没有人”的人住在里面。更不会有一个霸占了所有房间的恶客存在。要清空LIVERS,那就清吧,只要你设置了级联约束,就不会有任何离奇的事出现。唯一的后果只是一个无人居住的公寓而已,这不正是我们所要的吗?

NULL是真实存在的,尽管从某种意义上讲,我们无法解释它的存在。它是关系世界的黑洞。也许会让一些人不舒服,但回避它只会给我们带来更多的麻烦。

看不见摸不到

在《SQL-3参考大全》中,作者这样解释NULL的含义:未知或未定义。对NULL来说,有很多有趣的特性。

NULL是一个数据值,而且它属于一个域(?)。是的,例如一个字符串字段,其中的空值只能是一个字符串。尽管它的内容没有定义,或者未知,但它是字符串,这一点无可置疑。

NULL不是非法数据,这一点SQL-3 标准也说的很清楚。我们没有办法保存零分之一,但可以保存空值。虽然它是空值,是未定义,是未知,可它也的确是 一个合法的信息。

运算黑洞:对于NULL,一般的运算都会返回NULL。比如加减乘除,这简直就是一个黑洞一样。永远不会有什么数据等于NULL。当然,1不等于NULL,2也一样。可是,NULL也不等于NULL。说一个NULL等于NULL是错误的。所以我们只能比较它“是”或“不是”。为了避免混乱,SQL-3标准有一些约定。比如表达式 x=NULL,结果应当是UNKOWN 。 而表达式“x is NULL”,就得看情况,如果x是NULL或 False,就返回Ture(?);x是非NULL,返回False。有点奇怪是不是,它基于NULL不等于NULL。 这个规则的确为SQL标准所支持,遇到这样的数据库系统,可不要感到惊讶。

三值逻辑:《鹿鼎记》中的韦小宝,整人的秘诀之一就是“我问你话,是就点头,不是就摇头,不许你出声!”的确,通常我们的逻辑观点,总是基于这种二值逻辑体系,对就是对,错就是错。可在关系理论中,没有这么简单。有一种没有绝对是非的情况存在:NULL。这就是关系理论的三值逻辑。

还有一些常见的与NULL相关的情况。比如,统计函数(也有的文档称之为聚集函数、集函数)通常会忽略NULL。不过,假设有这样一个表T:

C

-----

1

2

NULL

NULL

我们分别执行两个查询:SELECT COUNT(*) FROM T和SELECT COUNT(C) FROM T, 猜猜会有什么不同?起初,我以为两个结果应当一样。结果,前一个是4,后一个是2。前一个等于4,显然基于NULL也是数据这个事实;而后一个结果为2,是由于统计C列时,COUNT忽略了NULL。

SQL-3标准中,搜索条件(WHERE和HAVING)只接受TRUE,而约束却只拒绝FALSE,二者对NULL的接受态度相反。所以我们前面见到的ROOMS表才可以把空值写入人员字段。而在排序时,却又没什么规律。SQL标准只作出了一个补充定义,所以每个DBMS的处理 ORDER BY的方法并不相同,当然NULL不是高于所有值就是低于所有值。

在《SQL-3参考大全》中介绍了更详细的关于NULL的内容。另外,书中还介绍了两位数据库专家C.J.Date和E.f.Codd关于NULL的不同论点(E.F.Codd甚至希望有四值逻辑)有兴趣的朋友可以找来一读。在实践中,我们还会遇到一些有趣的事,特别是联接查询中, NULL让我们的人生变得 “丰富多彩”。

由于种种原因,近几天我可能会放慢写作速度,但这并不代表我会放弃。在休整和充电之后,我会回到我所擅长的实战领域。再次感谢每一位关心《SQL Story》的读者。

0 0

相关博文

我的热门文章

img
取 消
img