MSSQL教程之在 SQL Server 中公道的利用 LEFT OUTE...
你看出了作者的深度？深处半米！当初是冲那么多的大牛给他写序才买的，后来才发现无啥内容，作者也只是才用几年的新手，百花了几十两银子，再次感叹当今社会的虚伪与浮躁server好比我们想对或人的消耗项目举行汇总，对应以下两个表：Theme与ThemeDetail
Theme的纪录为：
ThemeID(int)ThemeName(varchar)
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并没有他们需要的那么快和灵活。 对于数据库来说，查询是数据库的灵魂，那么SQL查询效率究竟效率如何呢？下文将带对SQL查询的相关问题进行讨论，供您参考。 SQLServer的异构移植功能个人感觉最好了。（如果对比过SQLServer的链接服务器和Oracle的透明网关的朋友会发现SQLServer的sp_addlinkedserver(openquery)异构数据库系列比Oracle真是强太多了。） varchar(max)\\\\nvarchar(max)类型的引入大大的提高了编程的效率，可以使用字符串函数对CLOB类型进行操作，这是一个亮点。 然后最好有实践机会，能够把实践到的和实践结合起来，其实理论思考是个非常困扰和痛苦的事情 其中最有名的应该是row_number了。这个终于解决了用临时表生成序列号的历史，而且SQLServer2005的row_number比Oracle的更先进。因为它把Orderby集成到了一起，不用像Oracle那样还要用子查询进行封装。 原来的计算字段其实和虚拟字段很像。只是管理方面好了而已，性能方面提高不多。但是SQL2005提供了计算字段的持久化，这就提高了查询的性能，但是会加重insert和update的负担。OLTP慎用。OLAP可以大规模使用。 XML字段类型更好的解决了XML数据的操作。XQuery确实不错，但是个人对其没好感。（CSDN的开发者应该是相当的熟了！） 一直以来个人感觉SQLServer的优化器要比Oracle的聪明。SQL2005的更是比2k聪明了不少。（有次作试验发现有的语句在200万级时还比50万级的相同语句要快show_text的一些提示没有找到解释。一直在奇怪。） having子句的作用是筛选满足条件的组，即在分组之后过滤数据，条件中经常包含聚组函数，使用having条件显示特定的组，也可以使用多个分组标准进行分组。
页:
[1]