对于学习SQL的人来说，JOIN可能会让人十分困惑 。弄清楚内部JOIN和外部JOIN之间的区别仅仅是个开始 。寻找将多个JOIN连接在一起的最佳方式更为困难 。内部优化器可能会帮上忙，但是当数据库管理员要求一个特别复杂的组合时 ， 它们就无能为力了 。
列（Column）是对空间的浪费“NoSQL”运动的一个伟大思想就是让用户从列中解脱出来 。如果有人想向条目添加新值，他们可以选择他们想要的任何标记或名称 。不需要更新模式来添加新列 。
SQL捍卫者在该模型中只看到了混乱 。他们喜欢表自带的顺序，不希望开发人员匆忙添加新字段 。他们有一定的道理，但是添加新列可能非常昂贵和耗时，特别是在大型表中 。将新数据放在单独的列中并使用JOIN对它们进行匹配会增加更多的时间成本和复杂性 。
优化器并非始终有用数据库公司和研究人员已经花费了大量时间开发优秀的优化器 ， 这些优化器可以分解查询并找到排序其操作的最佳方式 。
收益可能是显著的，但是优化器所能做的是有限的 。如果查询需要一个特别大的或细致的响应 ， 那么优化器不能只是说，“你真的确定吗？”它必须把答案集合起来，然后按照指令去做 。
有些数据库管理员只有在应用程序开始扩展时才意识到这一点 。早期的优化足以在开发期间处理测试数据集 。但是在关键时刻 ， 优化器无法发挥更多的功能 。
反范式化（Denormalization）将表视为垃圾面对想要更快性能的用户和不想为更大、更昂贵的硬件付费的用户，开发人员经常处于两难境地 。一种常见的解决方案是对表进行反范式化处理，这样就不需要复杂的JOIN或跨表操作 。
这并非一个糟糕的技术解决方案 ， 而且它经常获胜，因为磁盘空间已经变得比处理能力便宜 。但是反范式化也抛弃了SQL和关系数据库理论中最精华的部分 。当数据库变成一个长CSV文件时，所有这些花哨的数据库功能几乎都消失了 。
附加特性会破坏数据库多年来 ， 开发人员一直在为SQL添加新特性 ， 其中一些非常优秀 。但另一方面，有些新特性可能会导致性能问题 。一些开发人员警告称，“您应该特别小心子查询（Subqueries），因为它们会减慢所有操作的速度” 。另一些人则表示，“选择像公共表表达式、视图或windows这样的子集会使代码过于复杂” 。
例如，窗口函数（Window function）的设计是为了通过加速计算结果（如平均值）来加快基本数据分析的速度 。但是许多SQL用户会发现并使用一些附加的特性 。在大多数情况下 ， 他们会尝试新功能，只有当他们的机器慢得像爬行一样时才会注意到这些问题 。然后他们会需要一些经验丰富的数据库管理员来解释发生了什么以及如何修复它 。
原文标题：9 reasons SQL has got to go，作者：Peter Wayner
推荐阅读
- 喝红酒必须要醒酒吗?
- 袁咏仪，从146瘦到98斤，4个减肥方法可以让脂肪慢慢消失
- 时隔半年，再来看笑果文化的“消失”，原来都被罗翔说中了
- 备用金第七天晚上还可以，备用金是早上七点必须还掉
- 难怪郭襄必须被写死，你看中年的她有多猛，张三丰遇上她必败无疑
- 消失两年多后，再看赵薇如今的处境，47岁的她后悔了吗？
- 快速上手 PostgreSQL：掌握PSQL 命令行工具连接技巧
- 如何解决 MySQL 主从延时问题？
- 必须严惩！ 郭德纲、成龙、张国立等均被起诉，罚款或超30亿！
- 微信验证消息能如何看全，为什么微信互删后验证消息也消失了