分類: SQL

UNION ALL 語法其實有陷阱？介紹 BigQuery 最新的 UNION ALL BY NAME

Jumping發表留言
  1. SQL 中的 UNION ALL 其實有陷阱？
  2. UNION ALL 實際上會造成什麼問題？
  3. BigQuery 新功能 – UNION ALL BY NAME
  4. 總結
  5. 補充資料 – CORRESPONDING 語法
  6. 參考資料

SQL 中的 UNION ALL 其實有陷阱？

在查詢結構化資料庫時，常會使用到一個 SQL 語法：UNION ALL，但其實這個語法背後有一個很大的坑，就是在合併資料時，UNION ALL 其實會按照 SELECT 的順序來合併 (Positional 特性) ，所以當欄位資料型態一樣時，資料就會無視欄位名稱被按照順序合併起來。

按照順序來合併資料是什麼意思呢？
讓我們看一下範例

UNION ALL 實際上會造成什麼問題？

在這個範例中，我們想要讓名稱為 Number 和 Emoji 分別 UNION 在各自的欄位，由於這些值都是字串型態，所以 UNION ALL 是會成功執行的，但我們會發現結果並不是我們想要的那樣，因為我們的 SQL 中 SELECT 欄位的順序是錯的，UNION ALL 並不會自動幫我們依據欄位名稱去合併，這個問題除了 BigQuery 之外，其他資料庫像是 MySQL 或 PostgreSQL 也會有一樣的情況。

BigQuery 新功能 – UNION ALL BY NAME

閱讀更多»

[SQL] 為何應該要使用 “IS NULL" 而不是 “= NULL"？

Jumping發表留言

當我們想要找出某些欄位是 NULL 的資料…

做為資料工作者，在處理資料的時候經常會遇到所謂的空值「NULL」，也常看到這樣的值被存在資料庫的欄位中，當我們使用 SQL 想要找出某些欄位中是空值的資料，就會使用像下方這樣的 WHERE 去做篩選，但這樣其實無法得到我們想要的結果。

SELECT 
    column_1,
    column_2
FROM `my_table`
WHERE column_1 = NULL
閱讀更多»

[ ClickHouse ] uniq 和 uniqExact 的比較

Jumping發表留言

建議使用 uniq()

在 ClickHouse 中很常用又很相像的兩個 Aggregate Function: uniq() 和 uniqExact()

其實 uniqExact(x) 就等同 COUNT(DISTINCT x)，若是使用 COUNT(DISTINCT x) 會看到欄位名稱直接被轉成 uniqExact(x)

官方也有提醒：「除非一定要最精確的數字，否則建議使用 uniq」，因為 uniq 可以最佳化 memory 的使用。

以下是官方文件的描述：

uniq(x [, …])

Calculates the approximate number of different values of the argument.
計算輸入參數的不重複的大約數量。

參數可以是

  • Tuple
  • Array
  • Date
  • DateTime
  • String
  • numeric types.

Returned value

uniqExact(x [, …])

Calculates the exact number of different argument values.
計算輸入參數的不重複的精確數量。

可接受的參數和回傳的值跟 uniq 是一樣的。

參考資料

歡迎追蹤我的 IG 和 Facebook