前言 / Introduction
最近看了一個非常務實的資料庫教學影片（https://youtu.be/S50NWQXcBCs），講者用「Schema First」的方式帶大家從零開始設計一個可擴展的應用程式資料庫。 影片強調：大多數新手一開始就直接寫程式碼，結果後面資料庫變成一團亂，最後花幾倍時間重構。
今天就結合影片內容 + 常見的資料庫面試/報告問題，來整理一篇完整的筆記，特別回答以下經典提問：
- 資料庫在多層架構（multi-tier architecture）中屬於哪一層？
- 為什麼我們需要資料庫？
- 除了 MySQL 還能用哪些資料庫？
- 可以用 MariaDB 取代 MySQL 嗎？
- MySQL 跟 MariaDB 差在哪裡？
- 能不能只用檔案取代資料庫？
- 可不可以同時用檔案 + 資料庫來儲存資料？
正文 / Main Content
1. 資料庫在多層架構中屬於哪一層？
Which tier does the database belong to in multi-tier architecture?
現代 Web 應用最常見的是 三層架構（3-Tier Architecture）：
- Presentation Tier（表現層／前端） → 瀏覽器、React/Vue/Svelte、Flutter、iOS/Android App
- Application Tier / Logic Tier（應用層／商業邏輯層／後端） → Node.js、Spring Boot、Django、Laravel、NestJS、Go 等
- Data Tier（資料層／持久層） → 資料庫（MySQL、PostgreSQL、MongoDB…） + 檔案系統 / 物件儲存（S3）
結論：資料庫屬於 Data Tier（資料層），它是整個系統的「長期記憶體」。
2. 為什麼我們需要資料庫？
Why do we need a database?
簡單來說：檔案系統不適合當作主要持久化方案，原因如下：
- 沒有 ACID 特性（Atomicity, Consistency, Isolation, Durability）
- 難以處理並發（多人同時寫同一檔案容易壞掉）
- 查詢效率差（想找「所有 2025 年註冊且台北的用戶」要自己寫程式掃描）
- 沒有索引、沒有事務、沒有外鍵約束
- 備份、復原、分片、備援都很麻煩
資料庫解決了以上問題，讓我們可以：
- 安全地儲存大量結構化/半結構化資料
- 支援高效查詢（SELECT ... WHERE ... ORDER BY ... LIMIT）
- 保證資料一致性（事務）
- 支援多人同時存取
3. 除了 MySQL，還能用哪些資料庫？
Besides MySQL, what other databases can we use?
常見選擇大概可以分成三大類：
關聯式資料庫（RDBMS / SQL）
- PostgreSQL（目前最推薦之一，功能最完整）
- MySQL / MariaDB
- SQLite（適合小型專案、桌面 App、手機 App）
- Oracle Database（企業級）
- Microsoft SQL Server
- TiDB、CockroachDB（分散式 NewSQL）
NoSQL 系列
- 文件型：MongoDB、Firestore
- 鍵值型：Redis（快取）、DynamoDB
- 寬列式：Cassandra、ScyllaDB
- 圖形資料庫：Neo4j（擅長關係查詢，如社群關係）
其他新興/特殊用途
- ClickHouse（OLAP 分析）
- TimescaleDB（時序資料）
- Supabase / PlanetScale（現代化 MySQL/PostgreSQL 雲端服務）
4. 可以用 MariaDB 取代 MySQL 嗎？
Can we use MariaDB instead of MySQL?
答案：絕大多數情況下可以，而且很多新專案直接選 MariaDB。
MariaDB 是 MySQL 的原始作者（Monty Widenius）因為不滿 Oracle 收購 MySQL 後的走向，而在 2009 年 fork 出來的分支。
5. MySQL 與 MariaDB 的主要差異？
What are the differences between MySQL and MariaDB?
| 項目 | MySQL (Oracle) | MariaDB |
|---|---|---|
| 開源程度 | 有 Community 版，但企業功能推付費 | 完全開源，沒有閉源企業版 |
| 社群與發展速度 | Oracle 主導，更新較保守 | 社群活躍，功能迭代更快 |
| 新功能 | JSON 支援較晚，部分功能需付費 | 更早支援 JSON、CTE、Window Functions |
| 儲存引擎 | InnoDB 為主，MyRocks 等 | Aria、ColumnStore、MyRocks 等更多選擇 |
| 相容性 | – | 高度相容 MySQL（可直接替換） |
| 授權 | GPL + 商業授權 | 純 GPL |
| 目前推薦場景 | 已經在使用 MySQL 的舊專案、Oracle 生態 | 新專案、重視開源、想要更多新功能 |
2026 年現況：很多新專案（包含 Supabase、PlanetScale 的部分分支）更傾向 MariaDB 或 PostgreSQL。
6. 可以只用檔案取代資料庫嗎？
Can we use files instead of a database?
可以，但只適合極少數場景：
適合的情況：
- 靜態網站產生器（Hugo/Jekyll）
- 個人部落格的文章（Markdown 檔案）
- 極小型工具（幾百筆資料，單人使用）
- 遊戲存檔（.json / .yaml）
不適合的情況（強烈建議用資料庫）：
- 多用戶同時寫入
- 需要複雜查詢、排序、分頁
- 需要事務（轉帳、訂單）
- 資料量超過幾千筆
- 需要權限控管、備份機制
7. 可不可以同時用檔案 + 資料庫？
Can we use both files and database to store persistent data?
當然可以，而且這是非常常見的混合做法（Hybrid Storage）。
常見組合範例：
- 資料庫 存結構化資料：用戶資料、訂單、商品資訊、評論
- 檔案系統 / 物件儲存 存非結構化/大檔：頭像、商品圖片、PDF、影片（通常放 AWS S3、Cloudflare R2、MinIO）
- 資料庫 + 快取：Redis 存熱門資料（Session、排行榜）
- 資料庫 + 搜尋引擎：Elasticsearch / OpenSearch 存全文搜尋資料
這種做法能兼顧結構化資料的 ACID 與非結構化資料的彈性與成本。
結語 / Conclusion
影片裡講者說得很好：「好的應用程式不是從程式碼開始，而是從資料庫 Schema 開始。」
當你先把 ER Diagram 畫好、把關係理清楚、把資料型態與索引想清楚，後面寫程式才會順很多，也比較不容易在三個月後因為需求變更而整個推倒重來。
推薦大家看完這部影片（https://youtu.be/S50NWQXcBCs），然後實際用 dbdiagram.io 或 DrawDB 畫一個你正在做的 side project 的資料庫 schema，會有非常大的收穫！
你現在的專案是用哪一種資料庫呢？有沒有踩過什麼資料庫設計的雷？歡迎留言分享～