SQLStory摘录(六)————不可能的错误

发表于:2007-05-25来源:作者:点击数: 标签:
初学SQL的日子,感觉就像是刚学走路,步态可掬,跌跌撞撞。摔了不少可笑的跟头。拿出来大家娱乐一下,也互相提个醒,这样的错我们可以尽量避免的嘛。 先看这个: 例1 不合理的逗号: Select Field1, Field2, Field3, From MyTable 一执行就是个语法错误,什
 初学SQL的日子,感觉就像是刚学走路,步态可掬,跌跌撞撞。摔了不少可笑的跟头。拿出来大家娱乐一下,也互相提个醒,这样的错我们可以尽量避免的嘛。

先看这个:

例1 不合理的逗号:

Select Field1, Field2, Field3, From MyTable

一执行就是个语法错误,什么意思嘛,这可是从书上抄的哎,你不能这么对我……呵呵呵,其实嘛,错误在于我在最后一个字段名后面加了一个逗号。逗号是分隔字段名或表名的嘛,字段名和Form之间加个逗号算什么事?不要小看它,即使老手,也常出这个错,往往是因为这种情况:我们写了一个

Select Field1,

Field2,

Field3

From MyTable

……

然后调试过程中,我们可能会增删一些字段,尤其是在From关键字前面增删字段时,常会搞出事来,忘了看是不是字段间都由逗号分隔并且没有多余的逗号,常见是:

Select Field1,

Field2,

From MyTable

……

或者

Select Field1,

Field2,

Field3

Field4

From MyTable

……

Field3和Field4之间应有的逗号不见了,要是你写的是“Select ……Field3 as “XXX” Field4…… ”还好,系统会马上发现这里有错,不让你通过语法检查。如果是像前面那样写就惨了,系统会以为这是你给Field3起的别名哪,它会老老实实地输出:

Field1 Field2 Field4

------------------------

…………………………

像我这样的大马虎很可能会因为“没有错”就这样过去了,或者很奇怪地找“我的Field3那里去了”?其实不见了的是Field4……

MCDBA教材中的SQL采用了一种写法,初看很奇怪,却能很有效地防止这类错误:

Select Field1

,Field2

,Field3

From MyTable

……

第一个字段前面有Select关键字,其它的字段前面全有逗号。这种写法不符合英语的风格,不过朋友们可以试试,当你选中某一个字段(单行),或某几字段(多行),拖动它们,剪切、粘贴,修改,几乎不会导致逗号错误。因为一般人的习惯,调试过程中最常改的就是最后几个字段。用这种写法,总能保证From和它前面的字段之间没有逗号,而每个段之间都有逗号。当然Select 和第一个字段之间有逗号这种错误我也犯过(我犯过的错太多了),不过我的经验是这种错误很容易就会被发现,不像前面提的那两种那么隐蔽。当然它真的看起起来不顺,所以我到现在也总想不起这么写,所以我到现在还是会有时犯这个逗号错误。值不值得,请读者自己选择吧。

例2 语言问题:

看看这一句,居然也有错?

Select Field1,

Field2,

Field3

From MyTable

是的,所有的逗号各就各位,而且这个语句如此简单,实在没什么可犯错的地方啊?其实……Field2后面的那个逗号是不是有点怪怪的?对了,它是个中文逗号,数据库引擎可不认识它。在别的场合里,可能犯这种错的机会还少一点,由于我们在数据库中大量的要和中文信息打交道,就会经常遇到这种事。不只是逗号,有时我们可能写一些中文的别名,所以用来标识它的双引号也有错写成中文的危险。在这方面,没什么特别的技巧,如果你只用这台机器写代码,不妨把中文输入法设成英语标点(我绝不会,因为要写文章),还有就是一定要用半角数字,用全角数字写算式,系统可认不出来。

给大家一个比较过分的中文错误:

Select  Field1,

Field2,

Field3+1,

    Field4 as “中文字段名”

From Mytable

看看,中英文混排是不是挺可怕的?

“Form”错误

这个比较简单,就不举例了,就是一个拼写错误。如果评SQL语言中最容易写错的关键字,From 一定位居榜首。For和Form 都是英语中很常见的单词。我相信像我这样一写顺了就把From写成Form的肯定还有。如果是在Microsoft SQL Server的查询分析器或InterBase的ISQL中,还比容易发现,因为From会被加粗或加蓝。不过我们经常要在客户端程序代码中嵌入SQL(比如Delphi编程),那时就比较容易出这个错了。就在今天白天写程序时,我还在JavaScript脚本中把一个“Form”写成了“From”,这回光想着SQL,又给写反了。对此真的没什么好办法,小心再小心吧。

影子杀手——NULL值

有一个工资表,员工工资有两种,技术工资和业务工资,每个人根据岗位,发其中一种。现在统计这月公司一共下发多少钱,可能你会这么查:

SELECT SUM(技术工资+业务工资) FROM 工资表

而一回,结果是0。老板听说这事会比较高兴,因为他这个月少了一笔大支出,可你却面临被同事围攻的危险了。其实很简单,你忘了 NULL值。每个人的工资都有一项是NULL,直接一加起来就是NULL,一统计一分钱没有。

这次不只是细心的问题了,NULL值是SQL语言,乃至整个关系模型中最诡异的东西之一。它是什么?它什么也不是,它代表一切不可知的,未知的,未定义的东西。它不是0,更不是空格或空字符串。它不是信息,因为它不代表任何信息;但它也是信息,它告诉我们这里没有信息。它是任何类型的数据,因为任何数据都会有NULL;它不是任何类型的数据,因为用任何数据何它比较都没有意义。《SQL-3 参考大全》中这样评价:“这是不愉快而且在数学上是不合理的,但是是我们所得到的。”这是一个会让老手也为之发疯的东西。它让我想起很小的时候读到的一本童话,说童话王国下在被“乌有”吞没。“乌有”是什么?它什么也不是,它没有颜色,没有形状,没有气味,它就是什么也没有,在“乌有”中什么也看不到,对,它没有颜色,可并不代表它是黑的或透明的,“乌有”就是“乌有”,“乌有”侵吞一切,什么遇上“乌有”都会变成“乌有”。这本书还神神叨叨地写了其它一大堆很意识流很哲学的东西。我当时读了这本书整个人都变得神神叨叨的,天天想一些存在啊,自我本我什么的(那时我在上小学),以致于后来不小心当了程序员。后来见到NULL值我才明白,原来那本书的作者一定是一个数据库程序员,搞不好就是E.F.Codd本人。

NULL值是一个很可怕的东西,什么和它运算都会变成NULL,所以也别指望谁能和它比出大小,连NULL值自己也不行,想知道一个值是不是NULL不能用XXX=NULL,只能用XXX IS NULL。做联接查询时,尤其要小心NULL,联接有内联,有左右外联,有全联接,有Cross Join,就是这原因。更不要提写一些数学表达式,一定要小心它,必要时一定要用一些方法避免NULL值,比如在设计数据库时,该有默认值的字段要设默认值,该要求用户一定输入的就设为Not NULL。很多数据库系统有专用的功能来处理NULL值,在这方面MS SQL Server做的还不错,有一些比如ISNULL()之类的函数,功能很全面,用起来也很方便。

关于NULL值,绝对可以单独扩充出一个很有趣味的专题,但是它本身的确又是最常犯的技术错误,所以在这里一定要提。比如上面的错误,有两种方法可以避免:要么把两项空资的默认值都设为0,要么就用:

SELECT SUM(技术工资)+(业务工资) FROM 工资表

现在,你安全了。

今天先到这里,以后有机会,我们还会继续讨论一些更有意思,也更复杂的错误,搞清它们,对我们的进步也是很有帮助的。

原文转自:http://www.ltesting.net