《SQL反模式》读后感

年前买了这本书，在家没事看看，二百多页，没几天就看完了。

印象最深的就是这句“所谓专家,就是在一个很小的领域里把所有错误都犯过了的人”。可以看出来作者自己确实犯了很多很多错误，所以书里谈论的问题是实际应用中遇到的真问题，只这一点，我觉得买这本书值了。

其他优点就不说了，没那个谈一件事之前先来一大段吹捧的习惯，技术人，就事论事吧。

整本书看到的核心内容我觉得就是一点，提醒读者关系数据库的核心——“关系”二字。在思考具体应用的设计时，不要忘了关系数据库理论要面对的那些基本问题，为什么会有一范式、二范式、三范式、BC范式，面对的问题是什么。

但在我这些年的工作中，碰到的更多的情况是一 二范式大部分情况下会遵循，三范式就不一定了，是很不一定了。因为你不能单纯的就数据讨论数据，更多情况需要把这个放到一整套系统中就可用性、灵活性来考虑的。很多时候为了减轻某张表过大的访问压力，需要在别的表中存放冗余数据。

再拿最吸引我的第3章“单纯的树”这节举个例子，作者最终给出的比较好的解决方案“闭包表”确实很不错，但如果考虑另外的变量的话，实际情况就不一样了。该方案有个缺陷，即在中间的树关系表中最终将会产生大量数据，如果一个几千上万的原始数据，对应的关系表数据还是可以承受的，但放大到十万、百万呢，树层次有个四五层的话数据量将会多大？

对于作者不断强调的“关系”概念，我也有点保留，如果是做项目，或对已有系统的优化，很多人愿意在数据库的这些上面下功夫去探索。如果是做产品，或者是想要做产品，即便不做产品，原处的系统设计肯定都会弱化数据库的关系这个概念，仅仅把它当成一个存储层，应用的实际表现，如数据一致性等不可能首先依赖于数据库的设计，更多的是在程序中首先保证这一点。

 

这里无意贬低给出的方案的真实应用价值，而是提醒更多读者，从数据库设计角度考虑问题，书里给出的答案很不错，但真实应用不允许你只站在这个层次，第一位的是，你设计出来的东西的最终表现能否让客户接受。还是那句话，要综合考虑。