前面的文章中，我们初步见识了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》的读者。