仓酷云

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 768|回复: 9
打印 上一主题 下一主题

[学习教程] MSSQL教程之在 SQL Server 中公道的利用 LEFT OUTE...

[复制链接]
变相怪杰 该用户已被删除
跳转到指定楼层
楼主
发表于 2015-1-16 22:38:53 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
你看出了作者的深度?深处半米!当初是冲那么多的大牛给他写序才买的,后来才发现无啥内容,作者也只是才用几年的新手,百花了几十两银子,再次感叹当今社会的虚伪与浮躁server
好比我们想对或人的消耗项目举行汇总,对应以下两个表:Theme与ThemeDetail

Theme的纪录为:
ThemeID(int)ThemeName(varchar[10])
1就餐
2出差
3搭车
4别的

ThemeDetail的纪录为:
DetailID(int)ThemeID(int)Price(money)
1112.5
215
316
4211
5217
638

个中Theme中的ThemeID与ThemeDetail中的ThemeID是一对多的干系,对ThemeDetail表的了解以下:“就餐”用度为12.5+5+6=23.5元,“出差”用度为11+17=28元,“搭车”用度为8=8元,“别的”用度不存在,视为0处置,对应的SQL语句能够如许暗示:

SELECTTOP100PERCENTdbo.Theme.ThemeName,ISNULL(SUM(dbo.ThemeDetail.Price),0)
ASTotalPrice
FROMdbo.ThemeINNERJOIN
dbo.ThemeDetailONdbo.Theme.ThemeID=dbo.ThemeDetail.ThemeID
GROUPBYdbo.Theme.ThemeName,dbo.Theme.ThemeID
ORDERBYdbo.Theme.ThemeID

实行了局以下:
ThemeNameTotalPrice
就餐23.5
出差28
搭车8

关于消耗纪录不存的纪录假如就如许不显现它的话,利用内联的办法就能够满意请求了,可是我们如今必要对Theme中的每项均做统计,也包含“别的”项,因而我们应当接纳另外一种办法来完成,这就是左外联的办法,响应的SQL语句能够如许暗示:

SELECTTOP100PERCENTdbo.Theme.ThemeName,ISNULL(SUM(dbo.ThemeDetail.Price),0)
ASTotalPrice
FROMdbo.ThemeLEFTOUTERJOIN
dbo.ThemeDetailONdbo.Theme.ThemeID=dbo.ThemeDetail.ThemeID
GROUPBYdbo.Theme.ThemeName,dbo.Theme.ThemeID
ORDERBYdbo.Theme.ThemeID

实行了局以下:
ThemeNameTotalPrice
就餐23.5
出差28
搭车8
别的0

如许是否是就满意了我们的请求呢!
MySQL最初的开发者的意图是用mSQL和他们自己的快速低级例程(ISAM)去连接表格。经过一些测试后,开发者得出结论:mSQL并没有他们需要的那么快和灵活。
兰色精灵 该用户已被删除
沙发
发表于 2015-1-19 20:18:04 | 只看该作者
对于数据库来说,查询是数据库的灵魂,那么SQL查询效率究竟效率如何呢?下文将带对SQL查询的相关问题进行讨论,供您参考。
只想知道 该用户已被删除
板凳
发表于 2015-1-25 22:36:35 | 只看该作者
SQLServer的异构移植功能个人感觉最好了。(如果对比过SQLServer的链接服务器和Oracle的透明网关的朋友会发现SQLServer的sp_addlinkedserver(openquery)异构数据库系列比Oracle真是强太多了。)
海妖 该用户已被删除
地板
发表于 2015-2-9 22:06:55 | 只看该作者
varchar(max)\\\\nvarchar(max)类型的引入大大的提高了编程的效率,可以使用字符串函数对CLOB类型进行操作,这是一个亮点。
灵魂腐蚀 该用户已被删除
5#
发表于 2015-2-27 23:50:14 | 只看该作者
然后最好有实践机会,能够把实践到的和实践结合起来,其实理论思考是个非常困扰和痛苦的事情
再见西城 该用户已被删除
6#
发表于 2015-3-9 16:09:47 | 只看该作者
其中最有名的应该是row_number了。这个终于解决了用临时表生成序列号的历史,而且SQLServer2005的row_number比Oracle的更先进。因为它把Orderby集成到了一起,不用像Oracle那样还要用子查询进行封装。
第二个灵魂 该用户已被删除
7#
发表于 2015-3-17 00:10:23 | 只看该作者
原来的计算字段其实和虚拟字段很像。只是管理方面好了而已,性能方面提高不多。但是SQL2005提供了计算字段的持久化,这就提高了查询的性能,但是会加重insert和update的负担。OLTP慎用。OLAP可以大规模使用。
透明 该用户已被删除
8#
发表于 2015-3-17 00:10:23 | 只看该作者
XML字段类型更好的解决了XML数据的操作。XQuery确实不错,但是个人对其没好感。(CSDN的开发者应该是相当的熟了!)
简单生活 该用户已被删除
9#
发表于 2015-3-17 00:10:23 | 只看该作者
一直以来个人感觉SQLServer的优化器要比Oracle的聪明。SQL2005的更是比2k聪明了不少。(有次作试验发现有的语句在200万级时还比50万级的相同语句要快show_text的一些提示没有找到解释。一直在奇怪。)
小妖女 该用户已被删除
10#
发表于 2015-3-23 09:14:53 | 只看该作者
having子句的作用是筛选满足条件的组,即在分组之后过滤数据,条件中经常包含聚组函数,使用having条件显示特定的组,也可以使用多个分组标准进行分组。
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|Archiver|手机版|仓酷云 鄂ICP备14007578号-2

GMT+8, 2024-12-22 19:24

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表