那么如果它是這樣的簡單，會出現(xiàn)什么問題嗎？問題就是我們大多數(shù)人會直觀地認為這是命令式編程。如：“機器，做這，再做那，但在這之前，如果這和那都發(fā)生錯誤，那么會運行一個檢測”。這包括在變量中存儲臨時的編寫循環(huán)、迭代、調(diào)用函數(shù)，等等結(jié)果。
2、SELECT是在其他大多數(shù)語句后執(zhí)行，最重要的是，在FROM和GROUP BY之后。重要的是要理解當你覺得你可以從WHERE語句中引用你定義在SELECT語句當中的時候，。以下是不可行的：
WHERE z = 10 -- z is not available here!
如果你想重用z,您有兩種選擇。要么重復表達式:
SELECT A.x + A.y AS z
FROM A
WHERE (A.x + A.y) = 10
或者你使用派生表、公用表表達式或視圖來避免代碼重復。請參閱示例進一步的分析：
3、在語法和邏輯順序里，UNION都是放在ORDER BY之前，很多人認為每個UNION子查詢都可以進行排序，但根據(jù)SQL標準和大多數(shù)的SQL方言，并不是真的可行。雖然一些方言允許子查詢或派生表排序，但卻不能保證這種順序能在UNION操作后保留。
需要注意的是，并不是所有的數(shù)據(jù)庫都以相同的形式實現(xiàn)，例如規(guī)則2并不完全適用于MySQL,PostgreSQL,和SQLite上
從中我們學到了什么呢？
要時刻記住SQL語句的語法順序和邏輯順序來避免常見的錯誤。如果你能明白這其中的區(qū)別，就能明確知道為什么有些可以執(zhí)行有些則不能。
如果能設計一種在語法順序上實際又體現(xiàn)了邏輯順序的語言就更好了，因為它是在微軟的LINQ上實現(xiàn)的。
3、SQL是關(guān)于數(shù)據(jù)表引用的
因為語法順序和邏輯順序的差異，大多數(shù)初學者可能會誤認為SQL中列的值是第一重要的。其實并非如此，最重要的是數(shù)據(jù)表引用。
該SQL標準定義了FROM語句，如下：
<from clause> ::= FROM <table reference> [ { <comma> <table reference> }... ]
ROM語句的"output"是所有表引用的結(jié)合程度組合表引用。讓我們慢慢地消化這些。
FROM a, b
上述產(chǎn)生一個a+b度的組合表引用，如果a有3列和b有5列，那么"輸出表"將有8（3+5）列。
包含在這個組合表引用的記錄是交叉乘積/笛卡兒積的axb。換句話說，每一條a記錄都會與每一條b記錄相對應。如果a有3個記錄和b有5條記錄,然后上面的組合表引用將產(chǎn)生15條記錄(3×5)。
在WHERE語句篩選后，GROUP BY語句中"output"是"fed"/"piped"，它已轉(zhuǎn)成新的"output"，我們會稍后再去處理。
如果我們從關(guān)系代數(shù)/集合論的角度來看待這些東西，一個SQL表是一個關(guān)系或一組元素組合。每個SQL語句將改變一個或幾個關(guān)系，來產(chǎn)生新的關(guān)系。
從中我們學到了什么呢？
一直從數(shù)據(jù)表引用角度去思考，有助于理解數(shù)據(jù)怎樣通過你的sql語句流水作業(yè)的
4、SQL數(shù)據(jù)表引用可以相當強大
表引用是相當強大的東西。舉個簡單的例子，JOIN關(guān)鍵字其實不是SELECT語句的一部分，但卻是"special"表引用的一部分。連接表，在SQL標準中有定義（簡化的）：
<table reference> ::=
<table name>
| <derived table>
| <joined table>
如果我們又拿之前的例子來分析：
FROM a, b
a可以作為一個連接表，如：
a1 JOIN a2 ON a1.id = a2.id
這擴展到前一個表達式，我們會得到：
FROM a1 JOIN a2 ON a1.id = a2.id, b
雖然結(jié)合了數(shù)據(jù)表引用語法與連接表語法的逗號分隔表讓人很無語，但你肯定還會這樣做的。結(jié)果，結(jié)合數(shù)據(jù)表引用將有a1+a2+b度。
派生表甚至比連接表更強大，我們接下來將會說到。
從中我們學到了什么呢？
要時時刻刻考慮表引用，重要的是這不僅讓你理解數(shù)據(jù)怎樣通過你的sql語句流水作業(yè)的，它還將幫助你了解復雜表引用是如何構(gòu)造的。
而且，重要的是，了解JOIN是構(gòu)造連接表的關(guān)鍵字。不是的SELECT語句的一部分。某些數(shù)據(jù)庫允許JOIN在插入、更新、刪除中使用。
5、應使用SQL JOIN的表，而不是以逗號分隔表
前面，我們已經(jīng)看到這語句：
FROM a, b
高級SQL開發(fā)人員可能會告訴你，最好不要使用逗號分隔的列表，并且一直完整的表達你的JOINs。這將有助于改進你的SQL語句的可讀性從而防止錯誤出現(xiàn)。
一個非常常見的錯誤是忘記某處連接謂詞。思考以下內(nèi)容：
FROM a, b, c, d, e, f, g, h
WHERE a.a1 = b.bx
AND a.a2 = c.c1
AND d.d1 = b.bc
-- etc...
使用join來查詢表的語法
更安全，你可以把連接謂詞與連接表放一起，從而防止錯誤。
更富于表現(xiàn)力，你可以區(qū)分外部連接，內(nèi)部連接，等等。??
從中我們學到了什么呢？
使用JOIN，并且永遠不在FROM語句中使用逗號分隔表引用。
6、SQL的不同類型的連接操作
連接操作基本上有五種
EQUI JOIN
SEMI JOIN
ANTI JOIN
CROSS JOIN
DIVISION
這些術(shù)語通常用于關(guān)系代數(shù)。對上述概念，如果他們存在，SQL會使用不同的術(shù)語。讓我們仔細看看:
EQUI JOIN（同等連接）
這是最常見的JOIN操作。它有兩個子操作:
INNER JOIN(或者只是JOIN)
OUTER JOIN(可以再次拆分為LEFT, RIGHT,FULL OUTER JOIN)
例子是其中的區(qū)別最好的解釋:
-- This table reference contains authors and their books. -- There is one record for each book and its author. -- authors without books are NOT included author JOIN book ON author.id = book.author_id -- This table reference contains authors and their books -- There is one record for each book and its author. -- ... OR there is an "empty" record for authors without books -- ("empty" meaning that all book columns are NULL) author LEFT OUTER JOIN book ON author.id = book.author_id |
SEMI JOIN（半連接）
這種關(guān)系的概念在SQL中用兩種方式表達：使用IN謂詞或使用EXISTS謂語。"Semi"是指在拉丁語中的"half"。這種類型的連接用于連接只有"half"的表引用。再次考慮上述加入的作者和書。讓我們想象，我們想要作者/書的組合,但只是那些作者實際上也有書。然后我們可以這樣寫:
-- Using IN
FROM author
WHERE author.id IN (SELECT book.author_id FROM book)
-- Using EXISTS
FROM author
WHERE EXISTS (SELECT 1 FROM book WHERE book.author_id = author.id)
雖然不能肯定你到底是更加喜歡IN還是EXISTS，而且也沒有規(guī)則說明，但可以這樣說：
IN往往比EXISTS更具可讀性
EXISTS往往比IN更富表現(xiàn)力（如它更容易表達復雜的半連接）
一般情況下性能上沒有太大的差異，但，在某些數(shù)據(jù)庫可能會有巨大的性能差異。
因為INNER JOIN有可能只產(chǎn)生有書的作者，因為很多初學者可能認為他們可以使用DISTINCT刪除重復項。他們認為他們可以表達一個像這樣的半聯(lián)接：
-- Find only those authors who also have books
SELECT DISTINCT first_name, last_name
FROM author
這是非常不好的做法，原因有二：
它非常慢，因為該數(shù)據(jù)庫有很多數(shù)據(jù)加載到內(nèi)存中，只是要再刪除重復項。
它不完全正確，即使在這個簡單的示例中它產(chǎn)生了正確的結(jié)果。但是，一旦你JOIN更多的表引用，，你將很難從你的結(jié)果中正確刪除重復項。
更多的關(guān)于DISTINCT濫用的問題，可以訪問這里的博客。
ANTI JOIN（反連接）
這個關(guān)系的概念跟半連接剛好相反。您可以簡單地通過將 NOT 關(guān)鍵字添加到IN 或 EXISTS中生成它。在下例中，我們選擇那些沒有任何書籍的作者：
-- Using IN
FROM author
WHERE author.id NOT IN (SELECT book.author_id FROM book)
-- Using EXISTS
FROM author
WHERE NOT EXISTS (SELECT 1 FROM book WHERE book.author_id = author.id)
同樣的規(guī)則對性能、可讀性、表現(xiàn)力都適用。然而，當使用NOT IN時對NULLs會有一個小警告，這個問題有點超出本教程范圍。
CROSS JOIN（交叉連接）
結(jié)合第一個表中的內(nèi)容和第二個表中的內(nèi)容，引用兩個join表交叉生成一個新的東西。我們之前已經(jīng)看到，這可以在FROM語句中通過逗號分隔表引用來實現(xiàn)。在你確實需要的情況下，可以在SQL語句中明確地寫一個CROSS JOIN。
-- Combine every author with every book
author CROSS JOIN book
DIVISION（除法）
關(guān)系分割就是一只真正的由自己親自喂養(yǎng)的野獸。簡而言之，如果JOIN是乘法，那么除法就是JOIN的反義詞。在SQL中，除法關(guān)系難以表達清楚。由于這是一個初學者的教程，解釋這個問題超出了我們的教程范圍。當然如果你求知欲爆棚，那么就看這里，這里還有這里。
從中我們學到了什么呢？
讓我們把前面講到的內(nèi)容再次牢記于心。SQL是表引用。連接表是相當復雜的表引用。但關(guān)系表述和SQL表述還是有點區(qū)別的，并不是所有的關(guān)系連接操作都是正規(guī)的SQL連接操作。對關(guān)系理論有一點實踐與認識，你就可以選擇JOIN正確的關(guān)系類型并能將其轉(zhuǎn)化為正確的SQL。
7、SQL的派生表就像表的變量
前文，我們已經(jīng)了解到SQL是一種聲明性語言，因此不會有變量。（雖然在一些SQL語句中可能會存在）但你可以寫這樣的變量。那些野獸一般的表被稱為派生表。
派生表只不過是包含在括號里的子查詢。
-- A derived table
FROM (SELECT * FROM author)
需要注意的是，一些SQL方言要求派生表有一個關(guān)聯(lián)的名字（也被稱為別名）。
-- A derived table with an alias
FROM (SELECT * FROM author) a
當你想規(guī)避由SQL子句邏輯排序造成的問題時，你會發(fā)現(xiàn)派生表可以用帥呆了來形容。例如，如果你想在SELECT和WHERE子句中重用一個列表達式，只寫（Oracle方言）：
-- Get authors' first and last names, and their age in days
SELECT first_name, last_name, age
FROM (
SELECT first_name, last_name, current_date - date_of_birth age
FROM author
)
-- If the age is greater than 10000 days
WHERE age > 10000
注意，一些數(shù)據(jù)庫和SQL:1999標準里已將派生表帶到下一級別，,引入公共表表達式。這將允許你在單一的SQL SELECT中重復使用相同的派生表。上面的查詢將轉(zhuǎn)化為類似這樣的：
WITH a AS (
SELECT first_name, last_name, current_date - date_of_birth age
FROM author
)
SELECT *
FROM a
WHERE age > 10000
很明顯，對廣泛重用的常見SQL子查詢，你也可以灌輸具體"a"到一個獨立視圖中。想要了解更多就看這里。
從中我們學到了什么呢？
再溫習一遍，SQL主要是關(guān)于表引用，而不是列。好好利用這些表引用。不要害怕寫派生表或其他復雜的表引用。
8、SQL GROUP BY轉(zhuǎn)換之前的表引用
讓我們重新考慮我們之前的FROM語句：
FROM a, b
現(xiàn)在,讓我們來應用一個GROUP BY語句到上述組合表引用
GROUP BY A.x, A.y, B.z
這會產(chǎn)生一個只有其余三個列(!)的新的表引用。讓我們再消化一遍。如果你用了GROUP BY，那么你在所有后續(xù)邏輯條款-包括選擇中減少可用列的數(shù)量。這就是為什么你只可以從SELECT語句中的GROUP BY語句引用列語法的原因。
請注意，其他列仍然可能可作為聚合函數(shù)的參數(shù)：
SELECT A.x, A.y, SUM(A.z)
FROM A
GROUP BY A.x, A.y
值得注意并很不幸的是，MySQL不遵守這一標準，只會造成混亂。不要陷入MySQL的把戲。GROUP BY轉(zhuǎn)換表引用，因此你可以只引用列也引用GROUPBY語句。
從中我們學到了什么呢？
GROUP BY，在表引用上操作，將它們轉(zhuǎn)換成一個新表。
9、SQL SELECT在關(guān)系代數(shù)中被稱為投影
當它在關(guān)系代數(shù)中使用時，我個人比較喜歡用"投影"一詞中。一旦你生成你的表引用，過濾，轉(zhuǎn)換它，你可以一步將它投影到另一個表中。SELECT語句就像一個投影機。表函數(shù)利用行值表達式將之前構(gòu)造的表引用的每個記錄轉(zhuǎn)化為最終結(jié)果。
在SELECT語句中，你終于可以在列上操作，創(chuàng)建復雜的列表達式作為記錄/行的一部分。
有很多關(guān)于可用的表達式，函數(shù)性質(zhì)等的特殊規(guī)則。最重要的是，你應該記住這些：
1、你只能使用從“output”表引用產(chǎn)生的列引用
2、如果你有GROUP BY語句，你只可能從該語句或聚合函數(shù)引用列
3、當你沒有GROUP BY語句時，你可以用窗口函數(shù)替代聚合函數(shù)
4、如果你沒有GROUP BY語句，你就不能將聚合函數(shù)與非聚合函數(shù)結(jié)合起來
5、這有一些關(guān)于在聚合函數(shù)包裝常規(guī)函數(shù)的規(guī)則，反之亦然
6、還有…
嗯，這有很多復雜的規(guī)則。他們可以填補另一個教程。例如，之所以你不能將聚合函數(shù)與非聚合函數(shù)結(jié)合起來投影到?jīng)]有GROUP BY的SELECT語句中是因為：
1、憑直覺，沒有任何意義。
2、對一個SQL初學者來說，直覺還是毫無幫助的，語法規(guī)則則可以。SQL:1999年引入了分組集，SQL：2003引入了空分組集GROUP BY()。每當存在沒有顯式GROUP BY語句的聚合函數(shù)時就會應用隱式的空分組集（規(guī)則2）。因此，最初關(guān)于邏輯順序的那個規(guī)則就不完全正確了，SELECT的投影也會影響前面的邏輯結(jié)果，但語法語句GROUP BY卻不受影響。
是不是有點迷糊？其實我也是，讓我們看一些簡單的吧。
從中我們學到了什么呢？
在SQL語句中，SELECT語句可能是最復雜的語句之一，即使它看起來是那么的簡單。所有其他語句只不過是從這個到另一個表引用的的輸送管道。通過將它們完全轉(zhuǎn)化，后期地對它們應用一些規(guī)則，SELECT語句完完全全地攪亂了這些表引用的美。
為了了解SQL，重要的是要理解其他的一切，都要嘗試在SELECT之前解決。即便SELECT在語法順序中排第一的語句，也應該將它放到最后。
10.相對簡單一點的SQL DISTINCT,UNION,ORDER BY,和OFFSET
看完復雜的SELECT之后，我們看回一些簡單的東西。
集合運算（DISTINCT和UNION）
排序操作（ORDER BY,OFFSET..FETCH）
集合運算
集合運算在除了表其實沒有其他東西的“集”上操作。嗯，差不多是這樣，從概念上講，它們還是很容易理解的
DISTINCT投影后刪除重復項。
UNION求并集，刪除重復項。
UNION ALL求并集，保留重復項。
EXCEPT求差集（在第一個子查詢結(jié)果中刪除第二個子查詢中也含有的記錄刪除），刪除重復項。
INTERSECT求交集（保留所有子查詢都含有的記錄），刪除重復項。
所有這些刪除重復項通常是沒有意義的，很多時候，當你想要連接子查詢時，你應該使用UNION ALL。
排序操作
排序不是一個關(guān)系特征，它是SQL僅有的特征。在你的SQL語句中，它被應用在語法排序和邏輯排序之后。保證可以通過索引訪問記錄的唯一可靠方法是使用ORDER BY a和OFFSET..FETCH。所有其他的排序總是任意的或隨機的，即使它看起來像是可再現(xiàn)的。
OFFSET..FETCH是唯一的語法變體。其他變體包括MySQL'和PostgreSQL的LIMIT..OFFSET，或者SQL Server和Sybase的TOP..START AT（這里）。
讓我們開始應用吧
跟其他每個語言一樣，要掌握SQL語言需要大量的實踐。上述10個簡單的步驟將讓你每天編寫SQL時更有意義。另一方面，你也可以從常見的錯誤中學習到更多。下面的兩篇文章列出許多Java（和其他）開發(fā)者寫SQL時常見的錯誤：
· 10 Common Mistakes Java Developers Make when Writing SQL
· 10 More Common Mistakes Java Developers Make when Writing SQL