数据库开发者的《孙子兵法》
数据库？不就是MySQL之类嘛！
关系？不就是表嘛！
数据库设计？对着界面就能想出来嘛！
考虑不周全？改表嘛！
速度不够快？你建索引了吗？加索引嘛！
……
在我的开发经验中，类似的问答并不罕见。可是，这正常吗？
如今，DBMS似乎已经成了大多数应用中数据持久化当仁不让的选择；而大量的开发场合里，并没有专职的DBA存在，于是，数据库的安装、设计、维护、操作，往往由程序员兼任。不幸的是，在不少程序员那里，数据库的知识却是非常匮乏的——否则，就不会有上面这些问答了。
这也难怪，学校开设的数据库课程，往往太过古老——不少课本还在讲Foxbase（把课程当考古呢）；太过枯燥——1NF、2NF、3NF、BCNF，想想就头疼（况且有过开发经验的人都知道，有时不能完全规范化呢）；太过理论化——索引的检索比率（retrieve ratio）在10%左右是正常的（拜托，说那话的时候500,000行数据就算大表了，如今，这样的表司空见惯吧）……况且，如今的DBMS又这么智能，这么易用，索性彻底打破那些条条框框，按照直觉，怎样趁手就怎样来，似乎也是个不错的选择。
然而，问题似乎并不是这么简单，尤其是在应用日益复杂，对速度的要求又愈来愈严格的今天——数据库没设计好，复杂应用或是无法实现，或是效率极低；SQL语句写的不够简洁高效，速度就会大打折扣。日常开发中，这样的例子屡见不鲜：两条结果相同的SQL语句，一条需要0.05秒，一条需要0.2秒，如果一天执行50,000次，时间差别就是将近2小时！我见过某个普遍使用的论坛程序中，会把整个数据库锁死172秒的SQL语句；也遇见过设计不当的数据库，在里面60秒钟才能完成本来只需要5秒的查询。
每次遇到这种情况，我都在想，如果有一本书，从实际出发，教给我们“真正实用”的数据库的知识，该多好？
O’Reilly的《SQL语言艺术》（the Art of SQL），就是这样一本书！
光看名字，这本书讲的是SQL语言的“技艺”，然而随便翻阅两页，你就会发现，这其实是一本数据库实战全书。它的内容巨细靡遗，上至数据库设计的整体思想，下至SQL语句的调优细节；而且针对各种实际开发中遇到的各类典型问题，不但给出了解决方案，更给出了理由：
l 一家公司，会计部门、办公部门和生产部门的地址可能各不相同，我们该怎么办？留出三个字段吗？可是许多大多数时候，一个地址就够了，那么，另两个地址设为NULL，还是直接复制数据？如果设为NULL，判断并读取地址的操作，是应该放在数据库中呢，还是程序语言中呢？如果复制数据，如何保持更新的一致性呢？
l 如果要判断是否存在合适的数据，再做修改，应该先用count(*)吗？可是，有经验的程序员似乎有另外的办法，他们是怎么做的呢？
l 教科书上说，规范化是必须的，但是，有时候去规范化也是必须的，什么情况下应该去规范化，我们如何判断呢？
l 更多的索引能够带来更高的效率吗？系统地为外键建立索引，真的是良好的习惯吗？如果已经建立了多字段索引，是否还有必要为其中某个字段单独建索引？
l 数据量大了，表分区（或者“表空间”）是个不错的解决办法。然而，该如何分区呢？什么情况下选择循环分区？什么情况下选择数据驱动分区？
l 复杂的数据处理逻辑，是应该放到数据库内部（PL/SQL），还是交给外边的程序语言（C语言）？
类似的问题还有很多。可以说，这样的问题，许多时候并没有固定的、现成的答案，我们必须依据具体情况，进行考量，作出抉择。此时，书中介绍的经验，给出的抉择指导、判断依据，就显得尤其珍贵了。
除此之外，这本书还有两个地方深得我喜爱：一点是介绍了好的开发习惯，譬如在每条SQL语
句开头加上注释，以便调试（相信我，在复杂系统中，这个习惯非常、非常有用）；另一点是，作者写书借用了《孙子兵法》的智慧，所举的例子也多与军事有关
——譬如介绍索引时，所用的数据就是拿破仑麾下战将的名字——对军事有兴趣的程序员，读这本书时，应该能体会到更多的妙趣。
关系数据库与软件开发中的其它许多领域不同，它有完备的理论基础，又必须融入纷繁复杂的现实。the Art of SQL，或许更适合翻译为《SQL的技艺》，因为它是理论与现实之间，一座经验的桥梁。
《精通正则表达式，第3版》译者
http://www.cc2e.com.cn/indexbooks.htm
