标题     SQL Story摘录(七)————触摸NULL值    ccat(原作) 
  
关键字     关系数据库, SQL语言, NULL 
  
前面的文章中,我们初步见识了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-----12NULLNULL我们分别执行两个查询: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让我们的人生变得 “丰富多彩”。
 

解决方案 »

  1.   

    我也有遇到过这类的情况,
    一般我这么做。
    比如accessselect a, iff(isnull(b), '', b) 
     from table用一个iif和isnull来判断是否为null,为空了就把默认值显示为''
    sqlserver 里面是 case
      

  2.   

    我解决的办法:变量=Rs.Fields(0) & "",这样就不必判断该值是否为空了。
      

  3.   

    'Null'是个难取舍的问题.
    假如一般的数据, 我多会在建表时,
    以  
    create Table xxx
    ...
    CustName  char(25)  not null default '',
    OrderQty  integer   not null default 0,
    OrderDate Date      not null default now,
    ...硬性地限制了, 不容许null的出现. 
    但是有些情况, 是要有必要用null的, 如要统计订单总数 
    select count(OrderQty) from xxx
    group by CustName;
    便会把本为null的数目一起计算在内, 做成混乱. 但仍可以很容易的解决. 如
    上例我只消加上 where OrderQty <> 0 便可以了.
      

  4.   

    SQL Server中根本用不着CASE,一个ISNULL就搞定
    IsNull(a,'')即将字段a的值做了Null to ''的处理
      

  5.   

    is null   is not null判断,或者对表定义不能为空,但实际入库又空时,给它赋缺省值。
      

  6.   

    1:设定缺省值
    2: 用ISNULL
      

  7.   

    db2:
    value(colName,'')即可