5個編寫SQL查詢時常出現(xiàn)的錯誤分別是什么
這篇文章將為大家詳細講解有關(guān)5個編寫SQL查詢時常出現(xiàn)的錯誤分別是什么，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。
10年的上高網(wǎng)站建設(shè)經(jīng)驗，針對設(shè)計、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應(yīng)快，48小時及時工作處理。成都全網(wǎng)營銷的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動調(diào)整上高建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計，從而大程度地提升瀏覽體驗。創(chuàng)新互聯(lián)從事“上高網(wǎng)站設(shè)計”,“上高網(wǎng)站推廣”以來，每個客戶項目都認真落實執(zhí)行。
SQL被廣泛應(yīng)用于數(shù)據(jù)分析和數(shù)據(jù)提取。易上手，受到業(yè)內(nèi)人士的一致好評
盡管剛開始編寫SQL相當(dāng)容易，但是出錯率也是相當(dāng)?shù)母摺?/p>
下面是小芯整理的，在編寫SQL查詢代碼時大家經(jīng)常犯的5個錯誤。
示例很短，可能看起來很簡單。但是，在處理更大的查詢時，這些錯誤可就不會一目了然了。其中一些示例是特定于AWS Redshift的，而另一些則會出現(xiàn)在其他SQL數(shù)據(jù)庫(Postgres、MySQL等)。這些示例應(yīng)該在本地數(shù)據(jù)庫上運行，或者可以使用SQLFiddle在線運行。
示例SQL查詢可下載。
設(shè)定
創(chuàng)建兩個臨時表，其中有幾個條目有助于處理示例。
Sales表
該表包含帶有時間戳、產(chǎn)品、價格等的銷售條目。請注意，key列是唯一的，其他列中的值可以重復(fù)(例如ts列)。
DROP TABLE IF EXISTSsales; CREATE TEMPORARY TABLE sales ( key varchar(6), ts timestamp, product integer, completed boolean, price float );INSERT INTO sales VALUES ('sale_1', '2019-11-08 00:00', 0, TRUE, 1.1), ('sale_2', '2019-11-08 01:00', 0, FALSE,1.2), ('sale_3', '2019-11-08 01:00', 0, TRUE,1.3), ('sale_4', '2019-11-08 01:00', 1, FALSE,1.4), ('sale_5', '2019-11-08 02:00', 1, TRUE,1.5), ('sale_6', '2019-11-08 02:00', 1, TRUE,1.5);SELECT * FROM sales;
Hourly delay表
該表包含某一天每小時的延遲時間。請注意，ts列在下表中是唯一的。
DROP TABLE IF EXISTShourly_delay; CREATE TEMPORARY TABLE hourly_delay ( ts timestamp, delay float ); INSERT INTO hourly_delay VALUES ('2019-11-08 00:00', 80.1), ('2019-11-08 01:00', 100.2), ('2019-11-08 02:00', 70.3);SELECT* FROM hourly_delay;
1.按相同時間戳排序
檢索每種產(chǎn)品最近一次的售價:
SELECT price FROM (SELECT price, row_number() OVER (PARTITION BYproduct ORDER BY ts DESC) AS ix FROM sales) ASq1 WHERE ix = 1;
以上查詢的問題是多個銷售具有相同的時間戳。此查詢在相同數(shù)據(jù)上的連續(xù)運行可能得出不同的結(jié)果。下圖可見，產(chǎn)品0在2019-11-11-08 01:00有兩次銷售，價格分別為1.2和1.3。
用下一個錯誤修復(fù)這個查詢:)
2. 根據(jù)條件計算平均值
計算完成銷售的產(chǎn)品的平均價格。值是(1.1 + 1.3 + 1.5 + 1.5)/ 4，即1.35。
SELECT avg(price) FROM (SELECT CASE WHEN completed = TRUETHEN price else 0 END AS price FROM sales) ASq1;
當(dāng)運行查詢時，值為0.9。為什么?因為發(fā)生了這一計算：(1.1+0+1.3+0+1.5+1.5)/6是0.9。查詢中的錯誤是，將0設(shè)置為不應(yīng)包含的項。應(yīng)使用NULL而不是0。
SELECT avg(price) FROM (SELECT CASE WHEN completed = TRUETHEN price else NULL END AS price FROMsales) AS q1;
當(dāng)前，輸出和預(yù)計一樣是1.35。
3.計算整數(shù)列的平均值
計算含有整數(shù)的product列的平均值。
SELECT avg(product) FROM sales;
Product列中有3個0和3個1，預(yù)估平均值為0.5。大多數(shù)數(shù)據(jù)庫(例如最新版本的Postgres)將返回0.5，但是Redshift將返回0，因為它不會自動將product列強制轉(zhuǎn)換為float。因此需要將其強制轉(zhuǎn)換為float類型：
SELECT avg(product::FLOAT) FROM sales;
4. 內(nèi)連接
假設(shè)要對每天的所有銷售延遲進行匯總，并計算每天的平均銷售價格。
SELECT t2.ts::DATE, sum(t2.delay),avg(t1.price) FROM hourly_delay AS t2 INNER JOIN sales ASt1 ON t1.ts = t2.ts GROUP BY t2.ts::DATE;
結(jié)果是錯誤的!以上查詢將hourly_delay表中的delay列乘以倍數(shù)，如下圖所示。這是因為按時間戳連接，該時間戳在hourly_delay表中是唯一的，但在sales表中會重復(fù)。
為了修復(fù)這個問題，要在一個單獨的子查詢中為每個表計算統(tǒng)計信息，然后連接匯總。這使得時間戳在兩個表中都是唯一的。
SELECT t1.ts, daily_delay, avg_price FROM (SELECT t2.ts::DATE, sum(t2.delay) ASdaily_delay FROM hourly_delay AS t2 GROUP BYt2.ts::DATE) AS t2 INNER JOIN (SELECTts::DATE AS ts, avg(price) AS avg_price FROM sales GROUPBY ts::DATE) AS t1 ON t1.ts = t2.ts;
5.將列添加到ORDER BY
對上述錯誤的補救是顯而易見的。將key列添加到ORDER BY，這樣一來，查詢結(jié)果就可以在相同數(shù)據(jù)上重復(fù)出現(xiàn)——快速修復(fù)。
SELECT price FROM (SELECT price, row_number() OVER (PARTITION BYproduct ORDER BY ts, key DESC) AS ix FROMsales) AS q1 WHERE ix = 1;
為什么查詢結(jié)果不同于上一次運行?在進行“快速修復(fù)”時，key列被放在了ORDER BY中的錯誤位置。它應(yīng)該在DESC語句之后，而不是之前。查詢現(xiàn)在將返回第一筆銷售，而不是最后一筆銷售。再進行一次修正。
SELECT product, price FROM (SELECT product, price, row_number() OVER (PARTITION BYproduct ORDER BY ts DESC, key) AS ix FROMsales) AS q1 WHERE ix = 1;
本次修復(fù)使結(jié)果可重復(fù)。
關(guān)于5個編寫SQL查詢時常出現(xiàn)的錯誤分別是什么就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
網(wǎng)頁名稱：5個編寫SQL查詢時常出現(xiàn)的錯誤分別是什么
文章來源：http://m.jiaotiyi.com/article/geesjd.html