查询反模式 - GroupBy和HAVING的理解

为了最简单地说明问题,我特地设计了一张这样的表。

  

一、GROUP BY单值规则

  规则1:单值规则,跟在SELECT后面的列表,对于每个分组来说,必须返回且仅仅返回一个值。

  典型的表现就是跟在SELECT后面的列,如果没有使用聚合函数,必须出现在GROUP BY子句后面。

  如下面这个查询报错:

  

  因为对于按照部门分组之后,技术部分组有3个编号,销售部分组有2个编号,你让数据库显示哪个呢?

  如果假设你使用聚合函数COUNT(编号)之后,对于每个部门分组,就只有一个值 - 该部门下的人数:

  

  下面来实战下,我们希望查询出每个部门,最高工资的那个人的姓名,部门,工资。

  

  Shit,出师不利。第一次实战就错误了,我们来分析下。

  很明显,上面的姓名列是不符合单值规则的。我们的一厢情愿想法是,MAX(工资)之后,SQL Server就能自动帮我们返回不符合单值规则的‘姓名‘。但是很遗憾,SQL Server并没有这么做。理由如下:

  1.   如果两个人的工资相同,那么应该将哪个人的姓名返回?
  2.   如果我们使用的不是MAX()聚合函数,而是SUM、AVG等聚合函数(没有与之匹配的工资),那么姓名返回哪个?
  3.   如果在查询语句中使用了两个聚合函数,如MAX(),MIN()。那么应该返回的是MAX工资的姓名,还是MIN工资的姓名呢?

  综上所述,数据库是不可能能够根据我们输入的一个聚合函数,就帮助我们判断并显示出不符合单值规则的列的。

  对于MYSQL来说,当有这种不符合单值规则的列时,默认是返回这一组结果的第一条记录。而SQLite是返回最后一条。

  因此,对于以上查询,我们要另寻解决方案。

  解决方案1:关联子查询

SELECT 姓名,部门,工资 FROM 工资表 AS T1
WHERE NOT EXISTS (SELECT NULL FROM 工资表 AS T2 WHERE T1.部门 = T2.部门 AND T2.工资 > T1.工资)

  输出如下:

  

  完全符合要求。对于上面的关联子查询,可以理解为:

  遍历工资表的所有记录,查找不存在比当前记录部门相同且工资还大的记录。

  虽然,关联子查询的语法非常简单,但是性能并不好。因为对于每一条记录,都要执行一次子查询。

  解决方案2:衍生表

   使用衍生表的思路是,先执行一个子查询,得到一个临时结果集,然后用临时结果集和原表进行INNER JOIN操作。就能得到最高工资的人的信息。

  

  刚写出这个SQL语句时,觉得非常妙,理解了之后觉得非常妙。

SELECT 姓名,T1.部门,工资 FROM 工资表 AS T1 INNER JOIN
(
    SELECT 部门,MAX(工资) AS 最高 FROM 工资表    --执行查询,先记录两个字段 部门-最高工资
    GROUP BY 部门
) AS T2        --衍生表T2
ON T1.部门 = T2.部门 AND 工资 = 最高

  衍生表的方式性能优于关联子查询,因为衍生表的方式只执行了一次子查询。但是它需要一张临时表来存储临时记录。因此,这个方案也并不是最佳的解决方案。

  解决方案3:使用JOIN + IS NULL

  这是一个更妙的解决方案,当我们用一个外联结去匹配记录时,当匹配的记录不存在,就会用NULL来代替相应的列。

  我们先来看一条非常简答的SQL语句:

  

  从中你看到了什么?当T2表中,不存在比T1表中工资高的记录时就返回NULL。

  那么,那么,那么一个IS NULL是不是就解决问题了呢?

  

  好妙,好妙的方法,让人拍案叫绝的使用了OUTER JOIN。

  JOIN解决方案适用于针对大量数据查询并且可伸缩比较时。它总是能比基于子查询的解决方案更好地适应数据量的变量。

  解决方案4:对额外的列使用聚合函数

  我们知道,GROUP BY时,SELECT列表必须返回的是单值,那么我们可不可以通过使用聚合函数,让这个列返回单值呢?答案是可以的。

  

  其实,返回的数据是有问题的,当工资相同时,它就返回按姓名从大到小排列的第一个姓名。也就是说,当工资相同时,它只能够返回一条记录。

  我们将聚合函数换成MIN看看。

  

  解决方案5:Row_Number() + OVER

  WITH B AS
  (
      SELECT row_number() OVER(PARTITION BY Name ORDER BY CreateTime) AS part ,Score, Name, CreateTime
      FROM xxx
  )
  SELECT * FROM B WHERE Part = 1

  输出如下:

  

二、HAVING的理解

  WHERE与HAVING的区别:

  •   WHERE(分组前过滤):WHERE不能对聚合函数列进行过滤,因为执行WHERE的时候,分组尚未执行,聚合函数也未执行。
  •   HAVING(分组后过滤):主要用于对聚合函数列进行过滤,因为HAVING实在分组之后执行的。HAVING子句只能配合GROUP BY子句使用。没有GROUP BY子句时不能使用HAVING。

  错误使用WHERE的示例:

  

  正确使用WHERE与HAVING的示例:

  

时间: 2024-08-29 19:57:57

查询反模式 - GroupBy和HAVING的理解的相关文章

查询反模式 - GroupBy、HAVING的理解

为了最简单地说明问题,我特地设计了一张这样的表. 一.GROUP BY单值规则 规则1:单值规则,跟在SELECT后面的列表,对于每个分组来说,必须返回且仅仅返回一个值. 典型的表现就是跟在SELECT后面的列,如果没有使用聚合函数,必须出现在GROUP BY子句后面. 如下面这个查询报错: 因为对于按照部门分组之后,技术部分组有3个编号,销售部分组有2个编号,你让数据库显示哪个呢? 如果假设你使用聚合函数COUNT(编号)之后,对于每个部门分组,就只有一个值 - 该部门下的人数: 下面来实战下

查询反模式 - 正视NULL值

一.提出问题 不可避免地,我们都数据库总有一些字段是没有值的.不管是插入一个不完整的行,还是有些列可以合法地拥有一些无效值.SQL 支持一个特殊的空值,就是NULL. 在很多时候,NULL值导致我们的程序出现报错的现象,于是很多人就开始拒绝NULL值,想各种各样的方法来避免使用NULL值,但是很遗憾,NULL值恰恰就是满足我们的需要用于表示空值的. 空值经常存在于我们的数据库当中: 例如一个在职员工的离职时间. 例如一辆电力驱动的车的燃油消耗比. 二.反模式 很多人对于NULL值感觉到恐惧,原因

查询反模式 - 隐式的列

一.减少输入 程序员都喜欢使用通配符,如: SELECT * FROM Person 又或者省略字段名: INSERT INTO Person VALUES('10','张飞'...) 二.捷径会让你迷失方向 对于以上代码,如果你仅仅是在开发过程中用于查看一下数据库信息,又或者你只是写个小程序自己玩玩,这是没有什么问题的. 但是如果一旦你习惯于这样编写正式生产环境中的代码,那问题就随之而来了. 1.破坏代码重构 如果数据库更改了,比如增加了一列: ALTER TABLE Person Add A

查询反模式 - 全文搜索

一.目标:全文搜索 任何存储文本的应用都有针对这个文本进行单词或词组搜索的需求.我们使用数据库存储越来越多的文本数据,同时也需要搜索速度越来越快.Web应用尤其需要高性能和高扩展性数据库搜索技术. SQL基本原理就是一列中的单个数据是原子性的.也就是说,当我们对两个值进行比较时,通常是把两个值当成一个整体来比较,在SQL中比较子字符串总是意味着低效和不精确. 二.反模式:模式匹配断言 SQL提供了模式匹配断言来比较字符串,并且这是很多程序员用来搜索关键字的第一选择.最广泛使用的就是LIKE断言.

查询反模式 - 随机选择

一.问题提出 随机数在数据库中是经常用到的系统. 例如,一个广告系统希望随机选择一个广告来显示.随机推荐相关文章等等. 在SQL Server中查找随机数最简单的方法为: SELECT TOP 1 * FROM Person ORDER BY NEWID() 以上SQL语句的执行计划如下: 以上这种方法,需要对整个表进行一次排序,而且还无法有效地使用索引.加入我们只需要前几条数据,那么好不容易对整个结果集完成了排序,但绝大多数都浪费了. 以上的方式缺点如下: 随着数据量的增加,随机数的产生会变慢

SQL反模式学习笔记1 开篇

什么是“反模式” 反模式是一种试图解决问题的方法,但通常会同时引发别的问题. 反模式分类 (1)逻辑数据库设计反模式 在开始编码之前,需要决定数据库中存储什么信息以及最佳的数据组织方式和内在关联方式. 这包含了如何设计数据库的表.字段和关系. (2)物理数据库设计反模式 在确定了需要存储哪些数据之后,使用你所知的RDBMS关系型数据库技术特性尽可能高效地实现数据库管理. 这包含了定义表和索引,以及选择数据类型.也需要是要SQL的“数据定义语言”,比如Create Table语句. (3)查询反模

FWORK-数据存储篇 -- 范式与反模式 (学习和理解)

理解 1.第二范式的侧重点是非主键列是否完全依赖于主键,还是依赖于主键的一部分.第三范式的侧重点是非主键列是直接依赖于主键,还是直接依赖于非主键列.  2. 反模式 范式可以避免数据冗余,减少数据库的空间,减轻维护数据完整性的麻烦. 然而,通过数据库范式化设计,将导致数据库业务涉及的表变多,并且可能需要将涉及的业务表进行多表连接查询,这样将导致性能变差,且不利于分库分表.因此,出于性能优先的考量,可能在数据库的结构中需要使用反模式的设计,即空间换取时间,采取数据冗余的方式避免表之间的关联查询.

第二天,导出文件sql,查询,视图view,聚合函数,反模式,字符串处理函数

//把数据库导出到脚本文件mysqldump -uroot -p1234 --databases abc > d:/a/abc.sql CREATE TABLE stud( id INT PRIMARY KEY, NAME VARCHAR(32) NOT NULL, score NUMERIC(4,1));//把所有名字都设成"Mike"了UPDATE stud SET NAME="Mike" //只设置分数>=70的记录的NameUPDATE stud

SQL反模式学习笔记4 需要ID,建立主键规范

2014-10-11 10:23:31 目标:建立主键规范 反模式:每个数据库中的表都需要一个伪主键Id 在表中,需要引入一个对于表的域模型无意义的新列来存储一个伪值,这一列被用作这张表的主键, 从而通过它来确定表中的一条记录,即便其他的列允许出现适当的重复项.这种类型的主键列我们通常称其为“伪主键”或者“代理键”. 1.冗余键值:如果存在一个逻辑上更为自然的主键并且也满足unique约束,那么id就多余了: 2.允许重复项:伪主键本身确保了表的数据不会存在重复项,所以也就无法避免表中的其它数据