下面是SELECT语句的逻辑执行顺序：

FROM
ON
JOIN
WHERE
GROUP BY
WITH CUBE or WITH ROLLUP
HAVING
SELECT
DISTINCT
ORDER BY
TOP

几个示例

第一个示例

SELECT ID,COUNT(ID) AS TOTAL
FROM STUDENT
GROUP BY ID
HAVING TOTAL>2

实际执行顺序如下：

FROM STUDENT
GROUP BY ID
HAVING TOTAL>2
SELECT ID,COUNT(ID) AS TOTAL

TOTAL是在最后一句SELECT ID,COUNT(ID) AS TOTAL执行过后生成的新别名。因此，在HAVING TOTAL>2执行时是不能识别TOTAL的。

第二个示例

SELECT ID,COUNT(ID) AS TOTAL
FROM STUDENT
GROUP BY ID
ORDER BY TOTAL

实际执行顺序是：

FROM STUDENT
GROUP BY ID
SELECT ID,COUNT(ID) AS TOTAL
ORDER BY TOTAL

第三个示例

SELECT ID,COUNT(ID) AS TOTAL
FROM STUDENT
GROUP BY ID
ORDER BY COUNT(ID)

实际执行顺序：

FROM STUDENT
GROUP BY ID
SELECT ID,COUNT(ID) AS TOTAL
ORDER BY COUNT(ID)

第四个示例

SELECT FIRSTNAME+’ ‘+LASTNAME AS NAME, COUNT(*) AS COUNT
FROM STUDENT
GROUP BY NAME

实际执行顺序：

FROM STUDENT
GROUP BY NAME
SELECT FIRSTNAME+’ ‘+LASTNAME AS NAME,COUNT(*) AS COUNT

Reference

.bind()

$('a').bind('click', function() { alert("That tickles!") });

jQuery scans the document for all $('a') elements and binds the alert function to each of their click events

.live()

$('a').live('click', function() { alert("That tickles!") });

jQuery binds the alert function to the $(document) element, along with click and a as parameters. Anytime an event bubbles up to the document node, it checks to see if the event was a click and if the target element of that event matches the a CSS selector.

The live method can also be bound to a specific element other that document

$('a', $('#container')[0]).live(...);

.delegate()

$('#container').delegate('a', 'click', function() { alert("That tickles!") });

jQuery scans the document for $('#container'), and binds the alert function along with the click event and a CSS selector as parameters. Anytime an event bubbles up to $('#container'), it checks to see if the event was a click and if the target element of that event matches the CSS selector.

Why .delegate() is better than .live()

Why .live() or .delegate() instead of .bind()

There are 2 reasons we prefer delegate or live to bind:

• To attach handlers to DOM elements that may not yet exist in the DOM. Because bind directly binds handlers to the individual element, it cannot bind them to elements that aren't on the page yet.

If you were to run $('a').bind(...), and then new links were added to the page via AJAX, your bind handler would not work for these.

• Or to attach a handler to a single element or small group of elements, listening for events on descendent elements, instead of looping through and attaching the same function to 100 individual elements in the DOM. This would be the performance benefit of attaching a handler to one ancestor element(s) instead of directly attaching handlers to all elements on the page.

Reference

To start with, here's what OAuth does have in common with OpenID:

• They both live in the general domain of security, identity and authorization
• They are open web standards. Created and evolved by people with an itch to scratch and evolved pragmatically by a loose, fluid, alliance.
• They both celebrate decentralization. There is no central Open ID or OAuth server that holds all the security information in the universe.
• They both involve browser redirects from the website you're trying to use - the 'consumer' website - to a distinct 'provider' website. Meanwhile, those websites talk to each other behind the scenes to verify what just happened.
• The user can actively manage the provider website, exerting control over which websites can talk to it and for how long.

Open ID gives you one login for multiple sites. Each time you need to log into a site using Open ID, you will be redirected to your Open ID site where you login, and then back to the site.

OAuth lets you authorise one website - the consumer - to access your data from another website - the provider. For instance, you want to authorize a printing provider - call it Moo - to grab your photos from Flickr. Moo will redirect you to Flickr which will ask you, for instance, "Moo wants to download your Flickr photos. Is that cool?" and then back to Moo to print your photos.

Reference

To start with, here's what OAuth does have in common with OpenID:

• They both live in the general domain of security, identity and authorization
• They are open web standards. Created and evolved by people with an itch to scratch and evolved pragmatically by a loose, fluid, alliance.
• They both celebrate decentralization. There is no central Open ID or OAuth server that holds all the security information in the universe.
• They both involve browser redirects from the website you're trying to use - the 'consumer' website - to a distinct 'provider' website. Meanwhile, those websites talk to each other behind the scenes to verify what just happened.
• The user can actively manage the provider website, exerting control over which websites can talk to it and for how long.

Open ID gives you one login for multiple sites. Each time you need to log into a site using Open ID, you will be redirected to your Open ID site where you login, and then back to the site.

OAuth lets you authorise one website - the consumer - to access your data from another website - the provider. For instance, you want to authorize a printing provider - call it Moo - to grab your photos from Flickr. Moo will redirect you to Flickr which will ask you, for instance, "Moo wants to download your Flickr photos. Is that cool?" and then back to Moo to print your photos.

Reference