SQL Story摘录(一)————简单查询初探

原创 2002年06月06日 09:46:00

在CSDN上回贴时,我总是苦口婆心地劝告楼上楼下的朋友们多用联接。可响应甚微。往往一个简单的功能,也一定要写成子查询或游标,弄得非常复杂冗长。的确,这样写对于初学者来说,费力不费脑,思路比较好理解。所以往往得分的也是这些回贴。可事实上,如果你真正熟悉了SQL的编程风格,你会明白,联接查询才是最直接、最清晰、最有力的方法,而更好的办法就是无招胜有招,一条简单查询结束战斗。下面我举几个例子来证明一下这个观点。
例1-1、重复记录的查询和处理
总有一些朋友在网上问,一个表中,有重复的记录,怎么办?当然,一个设计风格良好的关系型数据库,每个表都应该有主键、有唯一索引,所以压根就不该有重复记录。不过有时还是会出现不该出现的事,比如“七.七事变”,比如“9.11”……咳咳,其实我想说的是,有时会有人根本没有数据库的概念,他就不知道主键是什么,或者随意建了一个自动标识的ID列充数(其实这也没什么,没有人天生会设计数据库,关键是愿不愿承认自己的不足并且改进)。更常见的是我们的数据可能来自一些电子表格或文本文件,导入到数据库中时才发现问题。
这里,我们建立一个表,表示某商店的存货。我有意没有加入任何索引和约束,这样,它会很容易地出问题(就像实验室里的裸鼠)。
CREATE TABLE PRODUCT(
ID INT, PNAME CHAR(20),
PRICE MONEY, NUMBER INT,
PDESCRIPTION VARCHAR(50))
现在,我们可以向其中插入一些数据:
IDPNAMEPRICENUMBERPDESCRIPTION
1Apple 123000

1Apple 123000

2Banana 16.997600

3Olive 25.224500

4Orange 15.995500

4Coco Nut 40.992000

5Pineapple 302500

6Olive 25.223000


这里有一些明显的问题,前两行完全一样,这样的重复数据一点意义都没有,只会添乱。InterBase还好点,在它的IBConsole中可以直接修改它们。可在SQL Server中,系统根本无法区分这两行,当我们试图对其中任一行修改时会收到一个错误信息。事实上,这也是一个关系型数据库应有的反应。那我们应该怎么办呢?
事实上,处理它的方法比找出错误数据还简单,联接查询都用不到。用一条SQL语句
SELECT DISTINCT * FROM PRODUCT
就可以把重复数据压缩掉,生成一个包括正常数据的数据集。结果如下:
IDPNAMEPRICENUMBERPDESCRIPTION
1Apple 123000

2Banana 16.997600

3Olive 25.224500

4Orange 15.995500

4Coco Nut 40.992000

5Pineapple 302500

6Olive 25.223000


对于支持SELECT …… INTO……FROM语句的数据库来说,这样一句
SELECT DISTINCT * INTO NewTable FROM PRODUCT
就可把数据导入到一个新表(NewTable )中。或者可以用INERT INTO …… SELECT DISTINCT * FROM ……把它导入到一个现有的表中。总之有了正确的数据集,再如何处理就好办了。相信大家知道这个合并重复数据的关键字DISTINCT后,再不会用游标来处理重复数据了吧。
这是第一步,有时可能我们不想一下把它们压缩掉,而是想先看看到底谁出了问题。好的,用下面的语句可以找出重复的记录,最右边一列“ROW_COUNT”表示这行数据在表中重复的次数:
SELECT ID, PNAME, PRICE, NUMBER, PDESCRIPTION, COUNT(*) ROW_COUNT
FROM PRODUCT
GROUP BY ID, PNAME, PRICE, NUMBER, PDESCRIPTION
HAVING COUNT(*) > 1
IDPNAMEPRICENUMBERPDESCRIPTIONROW_COUNT
1Apple123000NULL2

 


(所影响的行数为 1 行)
其实就是关键字GROUP BY …… HAVING和统计函数COUNT的一个简单运用,记得在GROUP BY 后面写上完整的字段列表。这表示我们要的是那些完全一致的数据,每个字段都一样。
PRODUCT表中的数据很多时,用前面的方法直接生成正确的数据集效率很低。现在有了这个结果集,我们可以高效率工作了。现在,我们用
SELECT ID, PNAME, PRICE, NUMBER, PDESCRIPTION
FROM PRODUCT
GROUP BY ID, PNAME, PRICE, NUMBER, PDESCRIPTION
HAVING COUNT(*) > 1
把重复的数据生成为一个经过压缩的正确数据集,用前述的方法导出到一个临时表中,然后用
DELETE FROM PRODUCT
WHERE ID IN (
SELECT ID
FROM PRODUCT
GROUP BY ID, PNAME, PRICE, NUMBER, PDESCRIPTION
HAVING COUNT(*) > 1
)
把重复数据从PRODUCT表中删除,再把压缩好的数据插入PRODUCT。现在PRODUCT表中不再有完全重复,不可标识的数据了。

Jbehave 学习笔记 (一)

1、什么是JBehave JBehave是一个用java编写的BDD(Behavior-Driven-Design)框架, java界的Cucumber。(注: 1、BDD主要的目的是能够从业务领域...
  • emma_6
  • emma_6
  • 2014年02月25日 10:46
  • 1300

敏捷开发(agile)中story

agile概念的比较详细的说明见:http://www.cnblogs.com/astar/archive/2012/02/28/Scrum.html 对于敏捷开发来说,User Story是开发的...
  • u013102039
  • u013102039
  • 2014年02月07日 15:24
  • 2848

SqlServer 执行计划及Sql查询优化初探

http://www.alixixi.com/program/a/2010062662233.shtml --建测试表 CREATE TABLE T_UserInfo ( Userid v...
  • wyqlxy
  • wyqlxy
  • 2013年09月16日 12:19
  • 1726

给自己做个地图故事 —— Trip to Greece

Esri 的 地图故事 很有意思,用句官媒的广告 “每个人都有要讲述的故事,利用地图的强大功能来讲述您的故事” …… 国庆假期将至,放点有趣的东西。如果喜欢分享,又想记录自己的过往,动手试试不错哦。如...
  • kikitaMoon
  • kikitaMoon
  • 2015年09月30日 13:53
  • 4172

敏捷测试(6)--基于story的敏捷基础知识

基于story的敏捷基础知识----需求管理(三) (3)每日站会 站会的目的有三个: (1)周知进度 仅从用户故事和任务的层面周知进度,任务进度只有两种状态:完成或未完成(完成百分比)。 (2)周...
  • kaka1121
  • kaka1121
  • 2014年01月16日 15:01
  • 2945

敏捷测试(3)--基于story的敏捷基础知识

基于story的敏捷基础知识----story编写 为什么使用Story? 软件行业40年多来,需求分析技术已经很成熟了,但是MRD驱动的过程不堪重负。因为往往MRD编写会占去很多时间,MRD评审又会...
  • kaka1121
  • kaka1121
  • 2014年01月13日 17:03
  • 2525

敏捷开发真正的重点不是 User Story 的拆分, 而是开发人员的能力

谈到敏捷开发, 许多人纠结的第一个问题便是: User Story 如何的划分? 更有不少人, 一遇到在 User Story 上有延迟交付或交付的质量不佳时, 便说是因为 User Story 的拆...
  • u011790275
  • u011790275
  • 2015年09月04日 11:34
  • 2006

SQL连接查询保障效率的简易原则

连接查询是数据库操作中很常用的
  • questionfish
  • questionfish
  • 2014年09月19日 16:37
  • 1452

15个初学者必看的基础SQL查询语句

数据库应用基础 -------------------------------- Start ----------------------- ^_^前言: 如果基本的语句你会的话,前三个基本的数...
  • qq_18353611
  • qq_18353611
  • 2016年11月14日 16:09
  • 1434

SQL查询优化器初探

项目中期,特意借了一本SQL优化的书,现将优化器的知识点总结如下: 查询优化器是关系型数据库管理系统的核心之一,决定对特定的查询使用哪些索引、哪些关联算法,从而使其高效运行。查询优化器是SQL Se...
  • u013266600
  • u013266600
  • 2017年07月17日 21:06
  • 241
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:SQL Story摘录(一)————简单查询初探
举报原因:
原因补充:

(最多只允许输入30个字)