Mingle索引
http://www.sharepointblogs.com/
http://MSSharePointDeveloper.com
http://www.sharepointreporter.com/
http://msevents.microsoft.com/cui/default.aspx?culture=en-US阅读全文having子句与where有相似之处但也有区别,都是设定条件的语句。
在查询过程中聚合语句(sum,min,max,avg,count)要比having子句优先执行.而where子句在查询过程中执行优先级别优先于聚合语句(sum,min,max,avg,count)。
简单说来：
where子句：
select sum(num) as rmb from order where id>10
//只有先查询出id大于10的记录才能进行聚合语句
having子句:
select reportsto as manager, count(*) as reports from employees
group by reportsto having count(*) > 4
以northwind库为例.having条件表达示为聚合语句。肯定的说having子句查询过程执行优先级别低于聚合语句。
再换句说话说把上面的having换成where则会出错。统计分组数据时用到聚合语句。
对分组数据再次判断时要用having。如果不用这些关系就不存在使用having。直接使用where就行了。
having就是来弥补where在分组数据判断时的不足。因为where执行优先级别要快于聚合语句。
聚合函数，这是必需先讲的一种特殊的函数：
例如SUM, COUNT, MAX, AVG等。这些函数和其它函数的根本区别就是它们一般作用在多条记录上。
SELECT SUM(population) FROM tablename
这里的SUM作用在所有返回记录的population字段上，结果就是该查询只返回一个结果，即所有
国家的总人口数。 通过使用GROUP BY 子句，可以让SUM 和 COUNT 这些函数对属于一组的数据起作用。
当你指定 GROUP BY region 时， 属于同一个region（地区）的一组数据将只能返回一行值．
也就是说，表中所有除region（地区）外的字段，只能通过 SUM, COUNT等聚合函数运算后返回一个值．
HAVING子句可以让我们筛选成组后的各组数据．
HAVING子句在聚合后对组记录进行筛选
而WHERE子句在聚合前先筛选记录．也就是说作用在GROUP BY 子句和HAVING子句前
看下面这几个例子吧：
一、显示每个地区的总人口数和总面积．
SELECT region, SUM(population), SUM(area)
FROM bbc
GROUP BY region
先以region把返回记录分成多个组，这就是GROUP BY的字面含义。分完组后，然后用聚合函数对每组中的不同字段（一或多条记录）作运算。
二、 显示每个地区的总人口数和总面积．仅显示那些面积超过1000000的地区。
SELECT region, SUM(population), SUM(area)
FROM bbc
GROUP BY region
HAVING SUM(area)>1000000
在这里，我们不能用where来筛选超过1000000的地区，因为表中不存在这样一条记录。
相反，HAVING子句可以让我们筛选成组后的各组数据．
本篇文章来源于 - http://www.itokit.com - web开发技术 原文地址是：http://www.itokit.com/bbs/viewthread.php?tid=11709
使用场景：关闭window的时候增加监听事件。
正确的使用方式：
Code
html代码：
Code
.x-panel-body p 
margin
注意：关闭窗口使用hide方法。过使用close方法，在第二次通过button创建window的时候会报错。
设置为起始页打开，应该使用F5浏览此网站；如果使用“在web浏览器“中打开将默认为default.aspx文件。
还记得警匪片上，匪徒们是怎么配合实施犯罪的吗？一个团伙在进行盗窃的时候，总有一两个人在门口把风，如果有什么风吹草动，则会立即通知里面的同伙紧急撤退。也许放风的人并不一定认识里面的每一个同伙；而在里面也许有新来的小弟不认识这个放风的。但是这没什么，这个影响不了他们之间的通讯，因为他们之间有早已商定好的暗号。
呵呵，上面提到的放风者、偷窃者之间的关系就是观察者模式在现实中的活生生的例子。
二、定义与结构
观察者（Observer）模式又名发布-订阅（Publish/Subscribe）模式。GOF给观察者模式如下定义：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
在这里先讲一下面向对象设计的一个重要原则：单一职责原则。因此系统的每个对象应该将重点放在问题域中的离散抽象上。因此理想的情况下，一个对象只做一件事情。这样在开发中也就带来了诸多的好处：提供了重用性和维护性，也是进行重构的良好的基础。
因此几乎所有的设计模式都是基于这个基本的设计原则来的。观察者模式的起源我觉得应该是在GUI和业务数据的处理上，因为现在绝大多数讲解观察者模式的例子都是这一题材。但是观察者模式的应用决不仅限于此一方面。
下面我们就来看看观察者模式的组成部分。
1)抽象目标角色（Subject）：目标角色知道它的观察者，可以有任意多个观察者观察同一个目标。并且提供注册和删除观察者对象的接口。目标角色往往由抽象类或者接口来实现。
2)抽象观察者角色（Observer）：为那些在目标发生改变时需要获得通知的对象定义一个更新接口。抽象观察者角色主要由抽象类或者接口来实现。
3)具体目标角色（Concrete Subject）：将有关状态存入各个Concrete Observer对象。当它的状态发生改变时, 向它的各个观察者发出通知。
4)具体观察者角色（Concrete Observer）：存储有关状态，这些状态应与目标的状态保持一致。实现Observer的更新接口以使自身状态与目标的状态保持一致。在本角色内也可以维护一个指向Concrete Subject对象的引用。
可以看得出来，在Subject这个抽象类中，提供了上面提到的功能，而且存在一个通知方法：notify。还可以看出来Subject和ConcreteSubject之间可以说是使用了模板模式（这个模式真是简单普遍到一不小心就用到了）。
这样当具体目标角色的状态发生改变，按照约定则会去调用通知方法，在这个方法中则会根据目标角色中注册的观察者名单来逐个调用相应的update方法来调整观察者的状态。这样观察者模式就走完了一个流程。
四、使用情况
GOF给出了以下使用观察者模式的情况：
1)当一个抽象模型有两个方面, 其中一个方面依赖于另一方面。将这二者封装在独立的对象中以使它们可以各自独立地改变和复用。
2)当对一个对象的改变需要同时改变其它对象, 而不知道具体有多少对象有待改变。
三、我推你拉
观察者模式在关于目标角色、观察者角色通信的具体实现中，有两个版本。一种情况便是目标角色在发生变化后，仅仅告诉观察者角色“我变化了”；观察者角色如果想要知道具体的变化细节，则就要自己从目标角色的接口中得到。这种模式被很形象的称为：拉模式——就是说变化的信息是观察者角色主动从目标角色中“拉”出来的。
还有一种方法，那就是我目标角色“服务一条龙”，通知你发生变化的同时，通过一个参数将变化的细节传递到观察者角色中去。这就是“推模式”——管你要不要，先给你啦。
这两种模式的使用，取决于系统设计时的需要。如果目标角色比较复杂，并且观察者角色进行更新时必须得到一些具体变化的信息，则“推模式”比较合适。如果目标角色比较简单，则“拉模式”就很合适啦。
在下面的示例中，dbo 是数据库所有者的缩写，用于限定存储过程和用户定义的函数的名称。dbo 是具有在数据库中执行所有活动的隐含权限的用户。由系统管理员角色中的任何成员创建的任何对象均自动属于 dbo。在下列示例中包含了 dbo 名称限定符。