闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧湱鈧懓瀚崳纾嬨亹閹烘垹鍊為悷婊冪箻瀵娊鏁冮崒娑氬幈濡炪値鍘介崹鍨濠靛鐓曟繛鍡楃箳缁犳娊鏌嶈閸撴瑧绮诲澶婄?闂侇剙鍗曢崶顒夋晬婵犲﹤鎳愰悞濂告煟鎼搭垳绉甸柛瀣╃劍缁傚秴饪伴崼鐔哄幐闂佸憡鍔戦崝宀勫焵椤掑倹鏆鐐茬箻閸╁嫰宕樿缁犳艾顪冮妶鍡楀闁稿﹥娲熷鎼佸箣濠€垹閰e畷鎯邦檪闂婎剦鍓熼弻鐔碱敊閻e本鍣板銈冨灪濡啫鐣烽悢鐓幬╅柕澶堝€曢ˉ姘舵煟閻斿摜鐭婄紒缁樺浮瀹曟岸骞掗幘鍓佺槇濠殿喗锕╅崜娑㈩敇濞差亝鈷戦柟绋垮閻撱儵鏌涘Ο鑽ょ煉鐎规洘鍨块獮妯肩磼濡粯鐝栭梻渚€鈧偛鑻晶鎾煙椤曗偓缁犳牠寮幘缁樺亹闁肩⒈鍓﹂崥瀣繆閻愵亜鈧牕螞娴h鍙忛柕鍫濐樈閺佸﹪鏌¢崶銉ョ仾闁抽攱甯掗湁闁挎繂鎳忛幉鍝ョ磼婢跺苯鍔嬪ǎ鍥э躬椤㈡洟濮€閳ュ厖娣梻浣筋嚃閸犳岸宕戦妶澶婃瀬闁告劦鍠栫壕鍏兼叏濡潡鍝洪柣鎿勭秮濮婄粯鎷呴崫銉ㄥ┑鈽嗗亜濞硷繝骞冮悙鐑樻櫇闁稿本绋戞禍妤呮⒑闂堟侗妲撮柡鍛矒閹繝鎮㈤崗鑲╁幐闂佹悶鍎弲娑欑濠婂牊鐓冪憸婊堝礈濞嗗骏鑰块梺顒€绉撮悞鍨亜閹哄秷鍏岄柛鐔哥叀閺岀喖宕欓妶鍡楊伓     濠电姷鏁告慨鐑藉极閸涘﹥鍙忛柣鎴f閺嬩線鏌涘☉姗堟敾闁告瑥绻橀弻锝夊閻樺樊妫岄梺杞扮閿曨亪寮婚垾鎰佸悑閹肩补鈧磭顔愰梻鍌氬€搁崑鍡涘垂闁秴桅闁告洦鍨伴崘鈧梺闈浤涢崨顖氬笌缂傚倸鍊峰ù鍥╃礄娴兼潙纾规繝闈涱儏閽冪喖鏌ㄥ┑鍡╂Ч闁哄懏鐓¢弻娑樷槈閸楃偞鐏嶉梺鍦厴娴滃爼骞冨Δ鍐╁枂闁告洦鍓涢ˇ銊╂⒑缂佹ɑ鎯堢紒缁樼箓椤曪絾绻濆顓炰簻闁荤偞绋堥埀顒€鍘栨竟鏇炩攽閻愭潙鐏︽い蹇庡嵆楠炲鏁冮埀顒傚閸ф鐓涢柛銉㈡櫅閺嬫梻绱掗悩鑽ょ暫闁哄瞼鍠撻埀顒佺⊕宀e潡骞婇崘顔界厽闊洤锕ュ▍濠囨煛瀹€瀣М妤犵偞岣块埀顒勬涧閹诧繝宕氬☉銏♀拺闁告繂瀚﹢浼存煟閳哄﹤鐏﹂柣娑卞櫍瀹曞爼顢楅埀顒傜矆閸岀偞鐓曟繝闈涘閸旀粓鏌¢崨顓滃仮婵﹦绮幏鍛存惞閻熸壆顐奸梻浣烘嚀閹诧繝骞冮崒鐐偓渚€寮介妸銉х獮婵犵數濮寸€涒晝绱炴惔鈾€鏀介柣鎰级閳绘洖霉濠婂嫮鐭掓鐐村灴閹虫粓鎮欓柅娑氱泿闂備浇顫夊畷妯衡枖濞戞瑧顩锋繝濠傚暊閺€浠嬫煃閳轰礁鏆為柕鍥ㄧ箖閹便劍绻濋崨顕呬哗闂佺懓寮堕幐鍐茬暦閻旂⒈鏁囬柣鏃偳归弲鎼佹⒑鐠囧弶鍞夋い顐㈩槸鐓ら柣鏂捐荡缂傛氨鎲搁弮鍫涒偓浣割潩鐠轰綍銊╂煥閺傚灝鈷旈柣锕€鐗撳娲箹閻愭彃濮岄梺鍛婃煥缁夋挳鍩㈠澶婎潊闁靛牆妫岄幏娲煟閻樺厖鑸柛鏂胯嫰閳诲秹骞囬悧鍫㈠幍闂佸憡鍨崐鏍偓姘炬嫹

45fan.com - 路饭网

搜索: 您的位置主页 > 网络频道 > 阅读资讯:SQL Story摘录集锦

SQL Story摘录集锦

2016-08-30 07:46:30 来源:www.45fan.com 【

SQL Story摘录集锦

前面的文章中,我们初步见识了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://www.45fan.com/a/question/69598.html
Tags: sql 摘录 Story
编辑:路饭网
关于我们 | 联系我们 | 友情链接 | 网站地图 | Sitemap | App | 返回顶部