NoSQL

不以傳統關聯表格為主的資料庫類型，常見如文件型資料庫。

先用一句話理解

不以傳統關聯表格為主的資料庫類型，常見如文件型資料庫。

打個比方

像一份份彈性表單，每份可以有不同欄位。

什麼時候會遇到

資料結構彈性高、即時同步、文件型資料為主時。

再往深一點看

NoSQL 是一大類資料庫的統稱，共同點是「不依賴固定表格與 SQL 語法」，最常見的是文件型資料庫（如 MongoDB），把資料存成 JSON 形式的文件，每份文件可以有不同欄位。NoSQL 的優點是結構彈性——產品初期不確定欄位時可以快速迭代；Firebase Firestore 還內建即時同步，資料一更新前端自動刷新。但 NoSQL 不代表可以不思考資料設計：沒有 JOIN 的情況下，你常常需要把相關資料複製一份存進同一份文件，一旦那份資料要更新，就必須所有地方都改，容易造成不一致。

舉個例子

你用 Firebase Firestore 做一個聊天 App：每個聊天室是一份文件，裡面有 name、members 陣列、最後一則訊息。因為每個聊天室的成員數不固定，用 NoSQL 文件直接放陣列比建關聯表方便，而且 Firestore 還能即時推播新訊息給所有連線的用戶端。

常見誤解

- 以為 NoSQL 一定比較簡單，初期快速，但資料一複雜（例如訂單要查商品名稱、買家資訊）就需要手動處理多份文件，比 SQL JOIN 麻煩。
- 把需要強一致性的資料（如付款金額、庫存數量）放進 NoSQL，多個請求同時修改同一份文件時容易產生競態條件（race condition）。
- 沒有思考查詢需求就直接建資料結構，後來發現欄位完全不利於要查的條件，只能掃全表。