SQL 为什么是糟糕的，换个角度的确很糟糕-优快云博客

❝
开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3300人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群近400 9群 200+，开10群PolarDB专业学习群100+)

SQL是DBA公认的最好的操作数据库数据的语言，而开发对于SQL本身并不是这么看的，今天从一个开发者的角度，可以看看他们对SQL的看法为什么和DBA是不同的，我们试着分析一下。

第一个问题，SQL隐藏了很多实际的底层数据情况：

开发人员无论是用JAVA还是用Python等都是具有可扩展性的，因为在这些程序里面只要后端的程序的服务器足够的强悍，他们可以将数据读取到程序的缓存内进行数据的处理。

换到SQL在数据处理中将遇到很多的问题，因为隐藏在SQL下的事情太负责了。我们可以列一下，一个SQL在分布式，在单体上的语句是一致，或基本一致的，这与SQL的国际标准有关。在SQL下面我们会有数据库实例是分片还是单体，数据库表是分表还是单表，同一个语句在不同的情况下运行效率是完全不同，开发人员无法通过SQL语句来锚定程序执行时的性能和标准。

况且还要通过SQL解析器来进行操作，SQL执行的稳定性相对于程序来说，变动项较多。

第二个问题，SQL对于程序常用的数据类型，并不通用

这个问题从开发侧的角度来考虑，是这样的，JSON，XML等，在不同的数据库中进行数据的处理的方式千奇百怪，PostgreSQL, MySQL, Oracle, MSSQL,等这些数据库本身是无法进行统一的JSON ，xml数据的处理的，这也导致开发人员纵然知道这些数据库在处理JSON数据有自己的优势和特点，可以添加索引直接处理的情况下。

还是不愿意用这些数据库自有的方式处理JSON 数据，个根因就在这里，统一的处理JSON数据的方式对程序员更有利。

第三个问题，数据的预处理太麻烦

程序员处理数据的思路是对象，对于应用程序设计的思路大多是直接将数据作为一个对象来进行数据的处理来思考的。

SQL和数据库将这个工作变得负责，大量的应用程序设计中工作饱含了数据怎么从该数据库到程序，程序怎么在把数据塞入到数据库中，程序员经常讲的一句话是，开箱即用。

程序员本身通过SQL来处理数据，对于他们来说这并不是开箱即用的思路。

第四个问题，SQL不能实时处理数据

相信说到这个问题，DBA并不统一，数据是事实的，SQL执行返回的是实时的数据， SQL怎么不能实时处理数据了。

我们可以用程序员的思路理解，什么是实时，他们的实时是一个管道，如同KAFKA，在程序和数据之间建立一个管道，通过SQL后，如果可以持续的不断的拿到数据，主要通道不断，那么数据的变动都会发送过来的，对于他们来说是实时。

而数据库的思路是类似批处理的方式和概念，你告诉我做什么我去做，然后回给你。

第五个问题，对于DBA很简单，对程序员不友好的JOIN

这个问题来自于程序中的混合数据处理，比如我要几个表的数据，我可以将这些数据单独读入到我的程序缓存中，然后进行处理，而SQL并不是，SQL是通过一条SQL JOIN来解决这些问题，那么这里就有谁先谁后，程序员对于一些JOIN的语法，如INNER JOIN, JOIN ,LEFT JOIN, RIGHT JOIN，FULL JOIN等都不明确其中的含义，这也是大多数JOIN ，程序员都默认LEFT JOIN 的原因，因为这是最快避免错误，且能完成任务的JOIN的方法。

第六个问题，硬件性能与数据库范式之间的矛盾

这个问题从MONGODB的在强调数据设计与硬件并不强相关的部分，就能获得一个思路，程序员希望的数据是平铺的，也就是把有用的数据库放到一个集合更好，而根据关系数据库的三范式的理论，重复的数据不在一个数据库中的多个表存在，同时也不希望有一个800列宽的大表来处理数据，所以JOIN的计算就依赖于CPU和内存，而宽表的数据处理大多依赖更快速的磁盘，磁盘比CPU和内存要便宜的多，从数据处理成本的角度来说，反范式更有利于数据处理成本的廉价化。

第七个问题，负责SQL处理与数据有关的需要老DBA

程序员在处理数据中，是希望独立来处理问题的，而数据库的介入复杂的SQL的撰写，解析，分析就导致很多情况下，DBA的经验在大型的项目里面很重要，而程序员大多理解不了这个问题，大部分程序员的更新换代情况严重，35岁的程序员就如同稀有的动物，而35岁的DBA可能正在当年甚至也不算特别的老，经验的积累是需要时间的，虽然AI人工智能等，但对于一些无法体现在书面的部分，AI也很难获得口耳相传的DBA的踩坑经验。这就导致程序员在大项目里面依赖DBA，导致的不能独立处理项目的尴尬问题。