前言

大家好，歡迎來到第十一天！在 Day 10，我們成功整合了 Firebase Authentication，讓「省錢拍拍」擁有了使用者系統。我們現在可以區分不同的使用者，但這引出了一個新的、更核心的問題：

User A 的消費紀錄，該如何儲存才能確保 User B 無法看到？

如果我們將所有人的資料都混在同一個地方，不僅會造成查詢效率低下，更會引發嚴重的隱私安全問題。因此，在我們動手寫任何一行資料庫程式碼之前，今天我們要做一件更重要的事：設計資料庫的結構。

今天，我們將深入了解 Firebase 旗下強大的 NoSQL 資料庫 Cloud Firestore，並為我們的 App 設計一個既安全又可擴展的資料模型。

Step 1: 什麼是 Firestore？NoSQL 的核心概念

Cloud Firestore 是一個彈性、可擴展的 NoSQL 雲端資料庫。與傳統的 SQL 資料庫（如 MySQL）不同，它不使用「資料表 (Table)」和「資料列 (Row)」。

Firestore 的世界由兩個基本單位構成：

1. 集合 (Collection)：類似電腦中的「資料夾」。它是一個容器，專門用來存放「文件」。例如，我們可以有一個 users 集合，或是一個 products 集合。
2. 文件 (Document)：類似資料夾中的「檔案」。這是儲存資料的實際單位。每個文件都有一個唯一的 ID，其內容是由「欄位 (Field)」和「值 (Value)」組成的鍵值對，就像一個 JSON 物件。

Firestore 的黃金法則非常簡單：資料庫的結構永遠是「集合 -> 文件 -> 集合 -> 文件 -> ...」這樣交錯的層級。這個規則很嚴格：集合底下永遠只能放文件，文件底下則可以放欄位資料，或是下一層的集合 (即子集合)。

比喻：

• Firestore 資料庫 ≈ 一整個檔案櫃
• 集合 (Collection) ≈ 檔案櫃中的一個個抽屜 (例如：「使用者資料」抽屜)
• 文件 (Document) ≈ 抽屜裡的一個個檔案夾 (例如：user_A 的檔案夾)
• 欄位 (Field) ≈ 檔案夾裡的一張張資料紙 (例如：姓名、Email)

Step 2: 設計「省錢拍拍」的資料模型

使用「子集合 (Sub-collection)」

1. 我們建立一個頂層的 users 集合。
2. users 集合中的每一個文件，其 Document ID 就是該使用者的 User UID（我們在 Day 10 從 Firebase Auth 取得的唯一 ID）。這個文件本身可以存放使用者的個人資料，例如 Email、暱稱等。
3. 在每一個使用者文件底下，我們再建立一個名為 transactions 的子集合，專門用來存放這位使用者的所有消費紀錄。

資料路徑看起來會像這樣：

/users/{user_A_uid}/transactions/{transaction_1_id}
/users/{user_A_uid}/transactions/{transaction_2_id}
/users/{user_B_uid}/transactions/{transaction_3_id}

這個設計的好處是：

1. 資料隔離：User A 的所有資料都被天然地「鎖」在 /users/user_A_uid 這個路徑下，與其他使用者完全隔離。
2. 查詢高效：當 User A 要讀取自己的消費紀錄時，我們只需要查詢他自己的那個 transactions 子集合即可，範圍極小，速度飛快。
3. 安全性高：設定安全規則變得異常簡單。我們可以輕鬆寫下規則：「使用者只能讀寫自己 UID 路徑下的 transactions 子集合」。

Step 3: 在 Firebase 控制台建立資料庫

理論架構結束，讓我們動手建立資料庫。

1. 在 Firebase 控制台，點擊左側「建構」>「Firestore Database」。
2. 點擊「建立資料庫」。
3. 選擇「以測試模式啟動」。這會允許在接下來的 30 天內，任何人都能對你的資料庫進行讀寫。這在開發初期非常方便，但請記住，產品上線前必須修改為「正式版模式」並設定安全規則！
4. 選擇一個離你使用者最近的 Cloud Firestore 位置（這裡我們選擇 asia-east1 (台灣)）。注意：這個位置一旦選定，就無法更改！

Step 4: 手動建立第一筆資料來驗證設計

為了加深理解，讓我們手動在控制台建立一筆符合我們設計的資料。

1. 在 Firestore 資料頁面，點擊「新增集合」。
2. 集合 ID 輸入 users。
3. 點擊「下一步」，進入建立文件的畫面。在 文件 ID 欄位，回到 Authentication 頁面，複製一個你昨天測試註冊的使用者 UID，然後貼上。
4. 為這個 User 文件新增幾個欄位，例如：email (String)，值為該使用者的 email；createdAt (Timestamp)，值為當前時間。儲存。
5. 現在，你已經有了一個 users 集合，裡面有一個使用者文件。請點選這個使用者文件。
6. 在右側，點擊「新增集合」，來建立一個子集合。
7. 集合 ID 輸入 transactions。
8. 點擊「下一步」。文件 ID 選擇「自動產生 ID」。
9. 為這筆交易文件新增欄位，例如：title (String) "晚餐", amount (Number) 200, date (Timestamp) 當前時間。儲存。

新增集合

新增子集合

最後建立的雲端資料

這樣就成功地在雲端手動建立了一筆符合的資料了！

今日結語

今天我們一行 Flutter 程式碼都沒寫，但卻完成了至關重要的一步——資料庫的架構設計。我們理解了 Firestore 的 Collection / Document 核心概念，並設計了一個利用「子集合」來隔離使用者資料的、可擴展且安全的資料模型。

明天，我們將正式回歸程式碼，學習如何對 Firestore 進行 CRUD (新增、讀取、更新、刪除) 操作，讓我們的 App 真正具備將資料存儲到雲端的能力！