SQL Story摘录（六）————不可能的错误
2024-07-21 02:09:04
供稿：网友
初学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 ｆｉｅｌｄ１,
field2，
field３＋１，
field4 as “中文字段名”
from ｍｙｔａｂｌｅ
看看，中英文混排是不是挺可怕的？
“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 工资表
现在，你安全了。
今天先到这里，以后有机会，我们还会继续讨论一些更有意思，也更复杂的错误，搞清它们，对我们的进步也是很有帮助的。
