前面的文章中，我们初步见识了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》的读者。
本文地址：http://com.8s8s.com/it/it21404.htm