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,导致的不能独立处理项目的尴尬问题。
跟我学OceanBase4.0 --阅读白皮书 (OB分布式优化哪里了提高了速度)
跟我学OceanBase4.0 --阅读白皮书 (4.0优化的核心点是什么)
跟我学OceanBase4.0 --阅读白皮书 (0.5-4.0的架构与之前架构特点)
跟我学OceanBase4.0 --阅读白皮书 (旧的概念害死人呀,更新知识和理念)
“合体吧兄弟们!”——从浪浪山小妖怪看OceanBase国产芯片优化《OceanBase “重如尘埃”之歌》
MongoDB “升级项目” 大型连续剧(4)-- 与开发和架构沟通与扫尾
MongoDB “升级项目” 大型连续剧(3)-- 自动校对代码与注意事项
MongoDB “升级项目” 大型连续剧(2)-- 到底谁是"der"
MongoDB “升级项目” 大型连续剧(1)-- 可“生”可不升
MongoDB 大俗大雅,上来问分片真三俗 -- 4 分什么分
MongoDB 大俗大雅,高端知识讲“庸俗” --3 奇葩数据更新方法
MongoDB 大俗大雅,高端的知识讲“通俗” -- 2 嵌套和引用
MongoDB 大俗大雅,高端的知识讲“低俗” -- 1 什么叫多模
MongoDB 合作考试报销活动 贴附属,MongoDB基础知识速通
MongoDB 使用网上妙招,直接DOWN机---清理表碎片导致的灾祸 (送书活动结束)
MongoDB 2023年度纽约 MongoDB 年度大会话题 -- MongoDB 数据模式与建模
MongoDB 麻烦专业点,不懂可以问,别这么用行吗 ! --TTL
免费PolarDB云原生课程,听课“争”礼品,重塑云上知识,提高专业能力
非“厂商广告”的PolarDB课程:用户共创的新式学习范本--7位同学获奖PolarDB学习之星
“当复杂的SQL不再需要特别的优化”,邪修研究PolarDB for PG 列式索引加速复杂SQL运行
“PostgreSQL” 高性能主从强一致读写分离,我行,你没戏!
POLARDB 添加字段 “卡” 住---这锅Polar不背
PolarDB 版本差异分析--外人不知道的秘密(谁是绵羊,谁是怪兽)
PolarDB 答题拿-- 飞刀总的书、同款卫衣、T恤,来自杭州的Package(活动结束了)
PolarDB for MySQL 三大核心之一POLARFS 今天扒开它--- 嘛是火
PostgreSQL 新版本就一定好--由培训现象让我做的实验
说我PG Freezing Boom 讲的一般的那个同学,专帖给你,看看这次可满意
PostgreSQL 无服务 Neon and Aurora 新技术下的新经济模式 (翻译)
“PostgreSQL” 高性能主从强一致读写分离,我行,你没戏!
全世界都在“搞” PostgreSQL ,从Oracle 得到一个“馊主意”开始
PostgreSQL 加索引系统OOM 怨我了--- 不怨你怨谁
PostgreSQL “我怎么就连个数据库都不会建?” --- 你还真不会!
PostgreSQL 稳定性平台 PG中文社区大会--杭州来去匆匆
PostgreSQL 分组查询可以不进行全表扫描吗?速度提高上千倍?
POSTGRESQL --Austindatabaes 历年文章整理
PostgreSQL 查询语句开发写不好是必然,不是PG的锅
这个 PostgreSQL 让我有资本找老板要 鸡腿 鸭腿 !!
MySQL相关文章
那个MySQL大事务比你稳定,主从延迟低,为什么? Look my eyes! 因为宋利兵宋老师
数据库优化系列
微软动手了,联合OpenAI + Azure 云争夺AI服务市场
HyBrid Search 实现价值落地,从真实企业的需求角度分析 !不只谈技术!
从“小偷”开始,不会从“强盗”结束 -- IvorySQL 2025 PostgreSQL 生态大会
被骂后的文字--技术人不脱离思维困局,终局是个 “死” ? ! ......
个群2025上半年总结,OB、PolarDB, DBdoctor、爱可生、pigsty、osyun、工作岗位等
从MySQL不行了,到乙方DBA 给狗,狗都不干? 我干呀!
SQL SERVER 2025发布了, China幸亏有信创!
删除数据“八扇屏” 之 锦门英豪 --我去-BigData!
写了3750万字的我,在2000字的OB白皮书上了一课--记 《OceanBase 社区版在泛互场景的应用案例研究》