後端開發 on Dev TLDRLSS

別被 SQLite 的隨性騙了！動態型別的陷阱是什麼？為什麼 ALTER TABLE 是半殘的？如何在 Node.js 中做好防禦性編程實現無痛資料表升級？

Tue, 19 May 2026 18:10:00 +0800

想像一個資源回收桶，你明明在上面貼了「寶特瓶專用」的標籤，結果別人丟了一張紙片進去，它居然默默收下，連一聲抗議都沒有？

這就是開發者第一次遇見 SQLite 型別系統時的驚悚體驗。

如果你習慣了 PostgreSQL 那種嚴格的海關作風（型別不對直接拒絕入境），SQLite 的隨性程度可能會讓你懷疑人生。

更恐怖的是，當你想 修改資料表結構 時，它會告訴你：

「資料表改不了，請蓋一棟新房子，把傢俱搬過去，然後把舊房子炸掉。」

SQLite 底層只有 5 種儲存類別

不管你在 CREATE TABLE 時宣告了什麼華麗的型別名稱（VARCHAR(255)、BIGINT、DECIMAL），SQLite 底層只認得這 5 種儲存類別：

儲存類別	說明
NULL	空值
INTEGER	整數（依數字大小自動佔用 1 到 8 bytes）
REAL	浮點數（固定 8 bytes）
TEXT	字串（預設 UTF-8 編碼）
BLOB	二進位資料（原封不動儲存）

你在欄位上設定的型別，對 SQLite 來說 只是一個「建議」，而不是「強制規定」。

這叫做 「型別親和性（Type Affinity）」，SQLite 會嘗試把你的資料轉成建議的型別，但如果轉不了，它照樣把原始資料塞進去，完全不報錯。

你可以在 SQLite 宣告一個 age INTEGER 欄位，然後塞入字串 '永遠的十八歲'，它會欣然接受。

三個最容易踩坑的型別陷阱

陷阱 1：沒有原生 Boolean

SQLite 沒有布林型別。True 和 False 只能用整數 1 和 0 代替。

當你用 Node.js 從 SQLite 撈出資料時，拿到的會是數字 1 或 0，不是 true 或 false。

如果你直接拿去做 if (user.is_admin === true) 的判斷，永遠不會成立。

陷阱 2：沒有 Date/Time 型別

SQLite 沒有日期時間型別。你只能把時間存成：

儲存方式	範例	優缺點
TEXT（ISO-8601 字串）	`'2026-05-19T18:00:00Z'`	最推薦，可讀性高，未來搬到 PostgreSQL 可無縫轉換
INTEGER（Unix Timestamp）	`1747656000`	佔用空間小，但人類不可讀

千萬不要存像 2026/5/19 下午六點 這種自創格式，否則未來做資料遷移時會是一場災難。

陷阱 3：字串塞進整數欄位不會報錯

在 PostgreSQL，你把字串塞進 INTEGER 欄位會直接噴錯。但 SQLite 只會默默嘗試轉換，轉不了就原樣收下。

這意味著你的資料庫裡 可能悄悄混進了髒資料，直到某天你的程式因為拿到非預期的型別而崩潰，才會發現問題。

防禦性編程：用嚴格的態度對待隨性的資料庫

面對 SQLite 的隨性，在 Node.js 開發中必須建立起 嚴格的防禦機制：

防禦層級	工具	作用
編譯期擋錯	TypeScript	在程式碼階段就擋下錯誤的型別
API 入口驗證	Zod	接收資料時嚴格驗證（確認 age 一定是數字）
底層型別轉換	Prisma / Drizzle ORM	自動處理 SQLite 和 PostgreSQL 之間的型別差異

把 「資料驗證的守門員」 從資料庫層移到 Node.js 應用層，這是同時駕馭 SQLite 開發速度與未來擴展性的關鍵策略。

使用 ORM 時，你只要在程式裡宣告 type: 'boolean'，ORM 存進 SQLite 時自動轉成 1/0，拿出來時自動轉回 true/false，完美遮蔽底層的型別差異。

ALTER TABLE 是半殘的：什麼能改、什麼不能改

SQLite 對資料表結構的修改支援非常有限：

操作	是否支援
新增欄位（`ADD COLUMN`）	支援
重新命名欄位（`RENAME COLUMN`）	支援
刪除欄位（`DROP COLUMN`）	支援（較新版本）
重新命名資料表（`RENAME TO`）	支援
更改欄位型態	不支援
增加/移除 `UNIQUE`、`NOT NULL` 限制	不支援
修改 Primary Key	不支援
修改 Foreign Key	不支援

一旦你需要做「不支援」的那些修改，SQLite 會要求你執行 「重建並搬移」 的策略。

重建搬移四步曲：SQLite 的資料表升級之道

既然無法直接改，官方建議的標準做法就是 蓋新房子、搬傢俱、炸舊房子、貼新門牌：

步驟	動作	說明
1	建立新表	`CREATE TABLE users_new (...)` 使用正確的結構
2	複製資料	`INSERT INTO users_new SELECT ... FROM users`
3	刪除舊表	`DROP TABLE users`
4	改名	`ALTER TABLE users_new RENAME TO users`

這四個步驟必須 一氣呵成，中途斷電或程式出錯就會造成資料遺失。

確保升級不遺失資料：兩道安全防線

防線 1：物理防禦，直接複製檔案

SQLite 的本質就是一個檔案。在執行任何結構變更前，先把 .db 檔案複製一份當備份。

const fs = require('fs');
fs.copyFileSync('my_project.db', 'my_project_backup.db');

萬一搞砸了，檔案蓋回去就瞬間復原。這是其他大型資料庫做不到的優勢。

防線 2：Transaction 包裝，資料庫的時光機

把搬家的步驟包在一個 Transaction 裡面，只要其中一步失敗，整個過程就會 自動還原（Rollback），當作沒發生過。

const Database = require('better-sqlite3');
const db = new Database('my_project.db');

const migrateData = db.transaction(() => {
  db.prepare(`
    CREATE TABLE users_new (
      id INTEGER PRIMARY KEY AUTOINCREMENT,
      name TEXT NOT NULL,
      age INTEGER NOT NULL DEFAULT 18
    )
  `).run();

  db.prepare(`
    INSERT INTO users_new (id, name, age)
    SELECT id, name, COALESCE(age, 18) FROM users
  `).run();

  db.prepare('DROP TABLE users').run();
  db.prepare('ALTER TABLE users_new RENAME TO users').run();
});

try {
  migrateData();
  console.log('資料表升級成功');
} catch (error) {
  console.error('升級失敗，資料已安全還原：', error.message);
}

「備份檔案 + Transaction 綁定」 就是你的資料庫遷移的安全氣囊。

用嚴格的態度駕馭隨性的 SQLite

用 嚴格的應用層架構 來駕馭隨性的 SQLite，享受它極速開發的優勢，同時避開未來的技術債。

SQLite 的型別系統很隨性，ALTER TABLE 也有諸多限制。

但只要在 Node.js 端做好 TypeScript 型別檢查 + Zod 驗證 + ORM 抽象層，再搭配 物理備份 + Transaction 的安全策略，你就能安心享受 SQLite 帶來的開發效率，同時為未來可能搬移至 PostgreSQL 鋪好後路。

Reference

不要什麼都用 PostgreSQL！SQLite 的嵌入式架構與零設定優勢是什麼？SQLite 的極限在哪？什麼時候該選 SQLite、什麼時候該選 PostgreSQL？

Tue, 19 May 2026 18:00:00 +0800

你有沒有想過，你每天打開的瀏覽器、手機裡的通訊軟體、甚至桌面上的筆記工具，裡面都藏著同一個輕巧的資料庫？

它不需要你安裝任何伺服器軟體，不需要設定帳號密碼，甚至不需要網路連線。它就是一個檔案，靜靜地躺在你的硬碟裡，隨時準備好為你服務。

這個低調的存在，就是 SQLite。

什麼是 SQLite？世界上部署最廣泛的資料庫

SQLite 是一個用 C 語言撰寫的 嵌入式關聯式資料庫引擎。

它沒有獨立的伺服器程式，而是直接嵌入你的應用程式中運作。

這跟你熟悉的 PostgreSQL 或 MySQL 完全不同。傳統資料庫是一台 獨立運作的伺服器，你的程式必須透過 網路協定（TCP/IP） 去跟它「通訊」。

但 SQLite 不一樣，它就是一段程式碼，直接跑在你的應用程式裡面，讀寫硬碟上的那個 .db 檔案。

比較維度	SQLite（嵌入式）	PostgreSQL（Client-Server）
運作方式	直接嵌入應用程式，無獨立伺服器	獨立伺服器程式，透過網路連線
設定需求	零設定，免安裝、免帳密	需要安裝、設定帳號密碼與防火牆
資料儲存	單一跨平台檔案	伺服器目錄下的多個檔案
備份方式	直接複製那個檔案	需要使用 pg_dump 等專用工具

正因為這種 「隨插即用」 的特性，SQLite 成為了世界上部署最廣泛的資料庫引擎。

從 Android 和 iOS 作業系統、Chrome 和 Firefox 瀏覽器，到 Adobe Lightroom、WhatsApp，甚至是 Airbus A350 的飛行系統，處處都有它的身影。

在 Node.js 中使用 SQLite

如果你是 Node.js 開發者，使用 SQLite 非常簡單。你不需要在電腦上安裝任何資料庫伺服器軟體，只需要安裝一個 npm 套件就能開始。

目前業界最常用的選擇：

套件名稱	特點	建議情境
`sqlite3`	最老牌，支援非同步 API	需要大量同時處理多個非同步任務
`better-sqlite3`	效能極佳，API 設計直覺，速度極快	首選推薦，追求開發效率與執行速度

用 better-sqlite3 建立資料庫並查詢，不用五分鐘就能完成：

const Database = require('better-sqlite3');
const db = new Database('my_project.db');

db.prepare('CREATE TABLE IF NOT EXISTS users (name TEXT, age INTEGER)').run();

const insert = db.prepare('INSERT INTO users (name, age) VALUES (?, ?)');
insert.run('John', 25);

const user = db.prepare('SELECT * FROM users WHERE name = ?').get('John');
console.log(user); // { name: 'John', age: 25 }

如果檔案不存在，better-sqlite3 會 自動幫你建立。

SQLite 支援的 SQL 語法比你想的強大

很多人以為 SQLite 很陽春，但它支援絕大多數的標準 SQL 語法，包含許多進階功能：

語法類別	支援項目
基礎操作	`SELECT`、`INSERT`、`UPDATE`、`DELETE`
資料定義	`CREATE TABLE`、`CREATE INDEX`、`CREATE VIEW`
進階查詢	`WITH` （CTE 遞迴查詢）、視窗函數（Window Functions）
衝突處理	`UPSERT` （`INSERT ... ON CONFLICT DO UPDATE`）
JSON 處理	`json_extract`、`json_array`、`json_object` 等內建函數
交易控制	`BEGIN`、`COMMIT`、`ROLLBACK`、`SAVEPOINT`
連接查詢	`INNER JOIN`、`LEFT JOIN`、`RIGHT JOIN` 和 `FULL OUTER JOIN`

SQLite 的核心哲學是「小而美」，它支援多數你日常需要的 SQL 能力，同時保持極致的輕量。

SQLite 的極限在哪？

輕巧是有代價的。如果把 SQLite 比喻為一間 只有一個結帳櫃檯的文青雜貨店，那 PostgreSQL 就是 配備 50 個收銀台的好市多。

1. 寫入大塞車

SQLite 在寫入資料時，會把整個資料庫檔案 鎖起來。

想像一間 只有一間廁所的餐廳：100 個人可以同時在外面看菜單（讀取），但只要有 1 個人進去把門鎖上（寫入），其他人就只能排隊等。

雖然開啟 WAL 模式（Write-Ahead Logging） 能改善讀寫並行的效能，但本質上仍然無法做到多執行緒同時寫入不同的資料行。

2. 無法跨多台伺服器

SQLite 的本質就是一個實體檔案。如果你的系統部署在多台伺服器上（水平擴展），這些伺服器 無法安全地共用同一個檔案。

3. 缺乏精細的權限管理

SQLite 沒有「使用者帳號」的概念。誰能在作業系統層面讀取那個 .db 檔案，誰就能看光、修改所有資料。

對於 需要嚴格個資審查的商務系統，這是無法接受的。

SQLite vs. PostgreSQL：技術選型決策

工具沒有好壞，只有適不適合。以下是一份幫助你做決策的終極檢核表：

提問	答「是」→ 選 SQLite	答「否」→ 選 PostgreSQL
後端伺服器是不是只有一台，或完全跑在本機端？	是	否（有水平擴展、多台機器）
系統行為是不是讀遠遠大於寫，且沒有高頻並行寫入？	是	否（大家會同時搶著寫入）
不需要精細的資料庫帳號權限或進階索引？	是	否（極度依賴進階功能）

更具體的情境對照：

情境	推薦選擇	理由
桌面軟體、手機 App、IoT 裝置	SQLite	資料跟著設備走，免安裝
個人部落格、展示型官網	SQLite	讀多寫少，省去維護伺服器成本
快速原型開發、Demo	SQLite	建個檔案就能開工
社群論壇、電商平台	PostgreSQL	高併發寫入，需要行級鎖
多台伺服器分散部署	PostgreSQL	需要跨機器共享資料源
醫療、金融等敏感系統	PostgreSQL	需要嚴格的角色權限控管

你的資料庫是隨身筆記還是中央總機

如果資料是 「單機、靜態、單一擁有者」，選 SQLite 享受極致的輕量與自由；

如果資料是 「雲端、動態、高度互動」，讓 PostgreSQL 接管。

SQLite 的核心哲學是 「應用程式的內部元件」，而 PostgreSQL 的定位是 「系統架構的獨立中樞」。

下次在架構決策時，別急著拿出 PostgreSQL，先問問自己：

「我的資料庫，是拿來當隨身筆記，還是中央總機？」

答案清楚了，選擇自然就明確了。