Database 是什麼？資料不是存在畫面裡，而是被系統管理起來

你在一個網站註冊帳號，輸入名字、Email 和密碼，按下送出。畫面跳到下一頁，看起來事情結束了。隔天你重新打開網站，登入之後，昨天建立的帳號還在；幾個月後換了一台手機，同一個帳號還是能用。這些資料顯然沒有留在昨天那個瀏覽器畫面裡，也不能只靠某一支程式暫時記住。系統需要一個地方，把資料持久地保存下來，而且之後還能快速找回、修改、刪除，甚至同時處理很多人的操作。這就是 database，也就是資料庫出現的地方。

Database 可以先理解成：一套用來保存、組織、查詢和管理資料的系統。 它不只是「一個裝資料的檔案」，因為真正的資料庫系統還要處理很多事情，例如哪些資料彼此有關、怎麼避免重複或衝突、誰可以讀寫、兩個人同時修改時怎麼辦，以及資料很多之後要怎麼查得夠快。

Table、row、column，其實就像一張很嚴格的表格

很多網站使用的是 relational database，也就是關聯式資料庫。它最常見的基本單位叫做 table。如果要存使用者資料，可以有一張 users table；每一位使用者是一筆 row，而 id、name、email、created_at 這些欄位則是 column。看起來有點像試算表，但資料庫對資料型別、關係與規則的要求通常更明確。

users

id | name   | email              | created_at
---|--------|--------------------|------------
1  | Mina   | mina@example.com   | 2026-09-16
2  | Yuki   | yuki@example.com   | 2026-09-16

如果所有東西都塞在同一張表裡，很快就會亂掉。假設這是一個成績系統，學生資料可以放在 students，課程放在 courses，成績放在 grades。grades 裡不需要重新複製學生姓名和課程名稱，只要記錄學生 id、課程 id 和成績，再透過這些 id 把不同 table 的資料連起來。這個「資料彼此有關聯」的概念，就是 relational database 名字裡 relational 的來源。

這樣做的好處不是單純看起來整齊。假設學生改名，如果姓名只存一個地方，就不需要去幾千筆成績紀錄裡逐筆修改；課程名稱變更也一樣。資料結構設計得好，系統比較容易保持一致，不會同一個人在不同地方突然出現兩種名字。

SQL 是拿來跟資料庫說話的語言，不是資料庫本身

關聯式資料庫通常會使用 SQL，全名是 Structured Query Language。SQL 是一套用來描述「我要哪些資料、我要新增什麼、我要改什麼」的語言。它不是某一個資料庫產品。PostgreSQL、MySQL、SQLite 都是資料庫系統，而 SQL 是它們共同使用的一類語言，只是各家的功能和語法細節不會完全一樣。

例如要找出 email 是某個值的使用者，可以寫出類似這樣的 query：

SELECT id, name, email
FROM users
WHERE email = 'mina@example.com';

這裡的 query 就是查詢。資料庫收到查詢後，會按照條件去找資料，再把符合的結果傳回來。除了 SELECT，SQL 還可以新增、更新、刪除資料，也能定義 table、constraint 和 index。真正的網站通常不會讓一般使用者自己打 SQL，而是由後端根據使用者的操作組成安全的查詢，再和資料庫溝通。

這也接回前一篇 Frontend、Backend 到底差在哪。你在前端按下「儲存」，後端先確認你有沒有權限、資料格式對不對，再決定該執行什麼資料庫操作。Database 本身不會理解「這個學生不准改別人的成績」這種產品規則，那通常是後端和資料庫權限設計一起負責的事情。

資料很多之後，不能每次都從第一筆翻到最後一筆

資料只有十筆時，怎麼找都很快；資料變成幾百萬筆後，搜尋方式就開始重要。如果每次登入都要從 users table 的第一筆一路檢查到最後一筆，系統很快就會變慢。資料庫因此會使用 index，也就是索引，替某些欄位建立更適合搜尋的資料結構。

可以把 index 暫時想成一本書最後面的索引頁。你想找「Transformer」，不需要從第一頁開始逐字讀，而是先從索引找到它出現在哪幾頁，再直接跳過去。資料庫 index 的實作比這複雜很多，而且不同類型的 index 適合不同查詢，但核心概念相近：用額外的儲存空間和維護成本，換取某些查詢更快。

所以 index 也不是越多越好。新增或修改資料時，相關 index 也要一起更新；如果什麼欄位都建 index，寫入成本和儲存空間都會增加。資料庫設計不是「把所有加速功能打開」，而是看實際查詢方式決定哪些地方值得建立索引。

Database 不只是存資料，還得處理「同時發生」

假設銀行帳戶裡有 1,000 元，你轉 300 元給另一個人。系統不能只做「你的餘額減 300」然後突然中斷，留下對方沒有收到錢的狀態。很多資料庫提供 transaction，把一組相關操作當成一個整體處理：應該一起成功，就一起成功；中間發生問題，就回到原本狀態。

這類能力在購物、訂票、庫存、付款和權限系統裡都很重要。資料庫不是單純把 JSON 丟進硬碟，而是在很多使用者同時讀寫時，盡量維持資料的一致性。不同資料庫對 transaction、一致性與分散式系統有不同設計，這也是為什麼「我可以用一個 JSON 檔存資料，為什麼還需要 database？」到了真正多人使用的產品裡，答案會很快變得明顯。

那 NoSQL 又是什麼？

不是所有資料都一定要放成傳統關聯式 table。文件型資料庫、key-value store、graph database、wide-column database 都有不同的資料模型，常被一起放在 NoSQL 這個大分類裡。它們不是「比較新的 SQL」，也不是「不用設計資料結構」。比較準確的理解是：它們選擇了不同的方式來表示、查詢和擴展資料。

所以 SQL 和 NoSQL 不是誰一定比較好的問題。如果資料有清楚的關係、需要 transaction、常做結構化查詢，PostgreSQL 這類 relational database 很自然；如果需求是大量 key-value 存取、特殊文件結構或圖關係，其他資料模型可能比較適合。有些現代系統甚至會同時用好幾種資料儲存方式，各自負責不同工作。

Database 跟 Backend 到底差在哪？

這兩個詞會一直一起出現，是因為後端很常需要資料庫，但它們仍然不是同一層。Backend 是執行產品邏輯的程式：驗證登入、檢查權限、計算價格、呼叫第三方 API、決定某個操作能不能做；Database 則專注在資料的儲存與存取。

例如有人要求修改成績。後端先判斷這個人是不是授課老師，確認輸入的分數是否合法，可能還要留下修改紀錄；最後才向 database 發出更新。資料庫可以進一步用 constraint、role 或 row-level security 擋住不合理操作，但「這個產品到底允許什麼」通常不能只靠資料庫自己猜。

這四個東西常常一起出現在同一張架構圖上，所以剛開始很容易混在一起。但把責任拆開後，其實沒有那麼神祕。你看到一個網站顯示自己的名字，背後可能只是前端向後端問「現在登入的是誰」，後端確認 session 之後去 database 找到使用者資料，再透過 API response 把名字送回前端。畫面只有最後那一小段，真正讓資料能留下來的，是後面整套系統一起工作。