SQL，是數據分析師的必備職場技能之一，不過SQL到底是用來做什麼的呢？SQL的英文全稱是Structured Query Language，中文則是結構化查詢語言，簡單來說，如果想要在資料庫找到資料，想要在資料庫創建新的資料表，SQL就是一套可以讀取資料庫以及儲存資料的語法。
剛轉職數據分析師時，雖然透過自學、大量刷題了解了SQL的基本語法，但是實際成為數據分析師之後，常常會發現現實中的數據比起題庫的資料來的複雜得多，例如，left join 的 key value 可能不只一個，Dimension table的值會出現重複值，創建一個表可能要找10幾20個資料表才能完整創建出來等，這一篇來分享我從寫 SQL過程中得到的重要概念。
釐清定義比直接埋頭苦寫更重要
剛開始寫SQL時我有一個壞習慣，那就是收到需求後，想也不想就直覺性的去找資料表，然後急著把需求解決掉。這樣的習慣在簡單的資料查詢相對不會有問題，但只要遇到資料串接、建資料表等比較複雜的資料處理，這個習慣容易造成資料表雖然指令沒有 Error，但是最終呈現的資料是錯誤的，或是不符合需求單位的需求。
我印象深刻有一次，我要查詢消費者的熱門消費城市，也就是呈現每個城市的消費人數、消費金額、消費訂單數，需要將訂單資料表連結客戶資料表，才能找到客戶所在的城市。但問題來了，所謂的「消費城市」到底要依哪個地址為主？是應該依消費者留的通訊地址來判斷？還是依消費者留的取貨地址來判斷？如果一個消費者通訊地址在台北市，送貨地址在桃園市，那應該把這筆訂單歸類在哪個縣市呢？這個問題沒有標準答案，「通訊地址」與「送貨地址」其實都可以，但是，究竟應該抓哪一個，就需要跟需求單位討論、確認才能知道。
從這個例子來看，當我沒有在寫表前先想好需要釐清的「定義」，在寫SQL查詢的過程中就容易一直卡住，甚至是遠離需求單位撈資料需求，讓自己白做工。
不只一次機會，不會就多試幾次
當 SQL 語法跟資料庫的規則不一樣的時候，送出查詢指令後系統就會報Error，例如語法錯誤可能會跳出 “missing expression”，寫錯資料表所在位置可能會跳出“table or view does not exist”，刷題過程不符合題旨查詢結果可能會跳出 “Wrong Answer”等。
起初接觸這個語法我也常常是滿滿的 Error ，一道SQL題目可能需要送出個4、5次才有辦法成功解題，出現錯誤總是讓我覺得心情很煩躁，想不到該怎麼解題，該用哪個語法也常常讓我懷疑自己能不能掌握這項技能，直到有一次，我在公司偶然看到每天都在寫SQL建表的工程師螢幕畫面，也出現了iT邦幫忙的查詢頁面，我才發現，原來每個人都一樣，每個人會有自己處理問題過程卡住的時候，也會有需要往外找資源、找資料的時候，不用因為覺得自己需要查參考範例就覺得自己不行的心態，寫SQL或是任何事情其實都一樣，過程中我們多多少少都會不熟戲、多多少少會做得不好、也可能都會犯錯，但是，改錯之後，結果好就好了啊，誰會在乎你寫SQL的過程中 Error 報錯幾次呢？誰會在乎成功的企業家過去失敗過幾次呢？不會就多找找資料，多看看別人怎麼寫，多試幾次總有一天會刻在自己的腦袋深處的！
搞懂規則，規則不對硬送指令也沒用
這個體悟發生在我轉換工作，使用不同資料庫系統的時候，雖然都是資料庫，但是不同的資料庫體系可能會在特定的語法中有不同的語法規則，以擷取現在時間的日期寫法為例，MySQL是用 NOW()，SQL Server則是用GETDATE()，讓我一開始超級不適應，甚至會做一些蠢事，例如同樣的語法修也不修，就直接再送一次查詢，想當然爾就是再次看到 Error。
轉換不同的資料庫系統，最重要的第一步絕對是搞清楚那套資料庫的語法規則是什麼，如果抱持著不更變的心態，在規則不對的情況下，就算是一樣的指令送了100次也不會從 Error 變成 Accepted。在熟悉規則的過程雖然很麻煩，也很不適應，但是當規則內化成習慣，下次就會得心應手了！
同樣的結果，解法不只一種
SQL雖然是一種有固定語法的語言，但同樣的資料查詢需求，寫法往往不只一種。如果你刷過SQL題目，可以特別注意討論串的留言內容，你就會發現同樣的題目，其他人可能會分享出不同的寫法，這也是我過去在煩悶的SQL刷題中，覺得特別有趣、特別可以引發我好奇心的環節。
以同樣是要找演員跟導演合作超過3次的查詢題目來說，有人可能直接用 Having 的語法來計算次數並做篩選，有人可能先用子查詢 + group by 語法後，再用 where 來篩選出3次以上的資料數，做法不同，但可以透過觀摩不同人的寫法，看看有沒有更簡易的寫法，了解相對不熟悉的語法，未來在不同的應用場景也可以更彈性的應用。
別想著一步到位，小規模測試更有效率
在我第一次幫忙建表的時候，我就犯下了這個想要一步到位的錯誤。那份資料需求是想看看過去6個月的庫存變動資料，需要從期初的庫存減掉過去6個月實際銷售出去的商品數量，同時還要考慮不同倉位的倉位庫存調動、銷售出去但是後來消費者退貨退回來的數量。聽到這個需求，是不是聽起來就很複雜？沒錯，超級複雜的！
但當時的我完全沒想著要小規模測試，居然直接開始從6個月的資料開始查詢，到最後雖然資料表寫完了，卻因為資料太大，我完全不知道要從哪裡開始驗證，最後只好再回到第一個步驟重新來過，後來，我改成以一個禮拜的資料調整，看看資料串連計算後跟當週期末的庫存數數字有沒有對上，等到小範圍的數據驗證沒有問題之後，才再放大資料範圍。
這個例子完全驗證了貪心想要一步到位的最後下場：被淹沒在資料海裡，當資料筆數幾十萬筆甚至幾百萬筆，我們更需要在過程中建立小範圍的簡單測試，甚至是在不同的資料處理步驟都再驗一次資料，確保沒有因為聯集、交集寫錯、遺漏資料，才不會最後滿心歡喜地寫完資料表，卻發現錯誤百出。
Sharon
Buy me a coffee 用行動支持我的內容創作
如果我的文章對你有幫助，歡迎用行動支持我的內容創作，小額贊助請我喝咖啡、留言或是寄信來跟我分享你的收穫，都會讓我持續有動力分享更多內容唷～
