不是数据库，不是开发，不是设计，因为它全都是

这本《SQL语言艺术》一直想读，一直到最近，自己对项目的管理，从过程到结果，一步一步的深入下来，从关心过程到最后关心结果。
为什么？
就是因为一句话：功能永远大于形式。可以这么说，过程（规范）都是形式，是非常重要，但当和功能比的时候，就不重要了。统一的过程是很重要，但如果一个组织连项目的成果都做不好的，何谈过程。所以，从务实的角度出发，自己逐渐的深入下来，做示范，找问题，纠偏差，找方法，从而去保障过程。
这本书在这个基调下，被我翻了出来，一读还真放不下手了。
他说的不是数据库，想了解数据库的怕是失望了。
他说的也不是开发，想了解的开发的怕是失望了。
他说的也不是设计，想了解设计的怕是失望了。
他说的是一个综合的过程，从数据库，到数据库设计，到基于数据库的开发，到SQL语句的编写，数据规模的不同，会导致复杂度的完全不同，数据规模在关系型数据库中，导致的语句复杂度（也可以说是性能效率）不是线性上升的，而是级数关系的。
一个普通的SQL语句，在一个由数据库完成基本优化的系统中，效率是1。那么具有一定优化的SQL语句，性能效率可以提升到10，如果你看下这个本书，应用书中教授的一些方法，性能效率可以再提升到100,。很恐怖的数据，一个设计再良好的数据库，在一个蹩脚的开发人员拼凑出来的代码里执行，得到的结果也不会好。
一个执行高效的应用，从界面层的数据组织，再到应用层的sql语句，再到数据库的查询，再到数据库的索引组织，这几个层面要做的工作虽然不尽一样，但可以肯定的说，这几个对最后效率的影响，是相乘的关系，也就是说是互相放大的。
所以，一个大数据量下的应用开发，不再是一个设计人员或者开发人员单纯的工作了，而是一个综合性的工作。
我们在数据库设计时，有多少人能够把这个数据架构作为项目重点考虑的问题。
不要说充分利用数据库的性能，充分利用中间件的性能，充分利用应用层的性能，充分利用界面层（信息展示的能力）的性能，连基本的达到要求不够，更谈不上利用这些层面的性能了。
任何一个层面的设计的不足，都不是后天的优化能够解决的。
读这本书的目的，绝对不是优化，然而优化绝对又是目的。
我其实想说，这本书，告诉你的是优化，但你要做的，是从设计做起。
也许，这一代的数据库会过时，因为现在基于noSQL技术的大数据架构正在成熟，但对于我们做传统应用系统的来说，我们以关系型数据库为主的应用开发来说，这本书，真应该去读下。就知道自己的数据库设计多么糟糕，写的sql语句多么蹩脚。