Day 13：商業邏輯的核心：在 n8n 中完美串接 PostgreSQL 資料庫與防雷指南

嗨，大家今天過得好嗎？歡迎來到鐵人賽 Day 13。

昨天我們用 Edit Fields 節點捏造了一組假資料，成功讓 SwiftUI 讀取並顯示結果。但一個真正的硬體菜單推薦系統，底層必須要有真實的報價資料庫支撐。

今天，我們要把寫死的假資料丟掉，正式讓 n8n 接入關聯式資料庫 PostgreSQL，讓系統具備去資料庫「撈真實時價」的能力！

課前準備：起一個 PostgreSQL 資料庫

為了維持我們用 Docker 開發的優雅傳統，如果你電腦還沒有裝 Postgres，請在你 Day 3 的 docker-compose.yml 裡面補上這段，把 DB 一起跑起來：

  postgres:
    image: postgres:15
    restart: always
    environment:
      POSTGRES_USER: myuser
      POSTGRES_PASSWORD: mypassword
      POSTGRES_DB: hardware_db
    ports:
      - "5432:5432"

(假設你已經在資料庫裡建好了一張 components 表，裡面有 name、type (CPU/GPU) 跟 price 等欄位。)

第一步：在 n8n 建立資料庫連線 (Credentials)

回到 n8n 的畫布，我們要在 Webhook 節點後面，新增一個 PostgreSQL 節點。

剛把節點拉出來時，n8n 會要求你設定連線憑證（Credentials）。

1. 點擊 Create New Credential。
2. 填入你的 Host (如果是 Docker 環境，可以填 postgres 或你的本機 IP)、Database、User 跟 Password。
3. 按下 Save 並點擊 Test Connection，看到 Connection testing successful 就代表 n8n 成功連上你的資料庫了。

第二步：寫 SQL 撈資料與「致命踩坑警告」

連上資料庫後，我們要設定 Postgres 節點的動作。
將 Operation 設為 Execute Query，這代表我們要自己寫 SQL 語法。

現在，我們想要撈出「價格小於等於使用者預算」的 CPU。
很多剛學 n8n 的新手，發現 n8n 支援 Expression (動態變數) 後，會很開心地這樣寫 SQL：

❌ 災難級寫法（千萬別這樣寫）：
SELECT * FROM components WHERE type = 'CPU' AND price <= {{ $json.budget }};

這是一個極度危險的資安大忌！
如果你直接把前端傳來的變數 {{ $json.budget }} 塞進 SQL 字串裡，你就是把大門敞開，歡迎駭客對你進行 SQL Injection (隱碼攻擊)。如果惡意使用者在前端預算欄位偷塞了一段 ; DROP TABLE components;，你的資料庫就當場灰飛煙滅了。

工程師的正確寫法：使用 Query Parameters

在 n8n 裡寫 SQL，請務必養成使用參數化查詢 (Parameterized Query) 的習慣。

1. 在 Query 欄位輸入：

   SELECT * FROM components 
   WHERE type = 'CPU' AND price <= $1 
   ORDER BY price DESC 
   LIMIT 5;
   

   (這裡的 $1 代表第一個參數變數，不是寫死的錢。)

2. 在 Postgres 節點下方找到 Options，點擊 Add Option。

3. 選擇 Query Parameters。

4. 在跳出來的欄位裡，填入我們從 Webhook 接收到的預算變數：{{ $json.budget }}。

這樣寫，n8n 的底層驅動就會自動幫我們過濾危險字元，確保傳進去的只是個單純的數字，徹底杜絕 SQL Injection。

測試資料流

現在，讓我們把節點連線起來：[Webhook] ➔ [PostgreSQL]。

點擊 Webhook 上的「Execute Workflow」進入監聽狀態，然後從 iOS 模擬器隨便送出一個預算（例如 10000）。
切回 n8n，打開 PostgreSQL 節點的右側 Output 視窗。你會看到，它完美地撈出了 5 筆價格低於一萬塊的 CPU 真實資料，並以 JSON 陣列 (Array) 的格式呈現！

小結

今天我們成功讓 n8n 與 PostgreSQL 對接，並且學會了如何安全地處理動態查詢。

現在我們的資料流上，已經有一批真實的硬體清單了。但實務上，商業邏輯不會只有「直進直出」這麼簡單，我們可能需要根據使用者的用途（3A 遊戲 vs 文書處理）去撈不同的表，或是設定不同的價格門檻。

明天，我們要來介紹 n8n 最強大的流程控制武器：If 與 Switch 節點，讓我們用視覺化的方式，把複雜的商業分流邏輯「畫」出來！

我們 Day 14 見！