為什麼選擇嵌入式資料庫 — 災難現場不需要資料庫管理員

一個被忽略的問題

在醫院裡，資料庫有專人維護。有 IT 部門負責安裝、設定、監控、備份、升級。出了問題，打電話給 DBA。

在災難現場，沒有 IT 部門。沒有 DBA。操作者是護理師和醫師。「設定資料庫」不在任何人的能力範圍內。

所以，xGrid 的資料庫選型不是從「功能最強」出發，而是從一個不同的問題開始：

這個資料庫能不能在零配置、零維護、零專業知識的情況下穩定運作？

傳統的醫院級資料庫需要什麼？

七個步驟，每一個都可能出錯。每多一個步驟，就多一個讓系統無法啟動的原因。

xGrid 用的嵌入式資料庫需要什麼？

一個檔案。 就這樣。

不需要安裝任何額外軟體。不需要設定任何帳號。不需要開啟任何額外的服務。系統啟動時自動連接這個檔案，就開始工作了。

護理師不需要知道什麼是「資料庫」。她只需要開機。

災難現場的醫療站可能有 10–15 台手機同時連線。護理師查詢病患資料、藥師確認庫存、醫師查看血庫狀態——這些讀取操作必須即時回應。

同時，另一個護理師正在登錄新的檢傷結果——這是寫入操作。

xGrid 的資料庫採用寫前日誌機制，讓讀取和寫入可以同時進行。15 台手機同時查詢，不會被一筆正在進行的寫入卡住。

而寫入操作則是排隊執行的：同一時間只有一筆寫入在進行。這聽起來像是限制，但在醫療場景中反而是優勢——排隊確保每一筆寫入都是完整的、有序的、不會互相衝突。一筆檢傷記錄不會因為另一筆同時寫入而被破壞。

xGrid 的資料庫結構經過 41 次升級——從最初的基本庫存表，到後來的血庫、手術追蹤、藥局調劑、全文搜尋。

每次升級都是自動的。系統啟動時，會自動檢查是否有需要執行的升級。如果有，靜默完成。如果某次升級失敗，自動還原，不影響已完成的部分。

護理師看到的只是：重啟服務後，系統多了新功能。她不需要跑任何指令、不需要看任何提示、不需要做任何決定。

在用行動電源供電的環境中，斷電不是假設，而是日常。

如果資料庫在寫入過程中斷電，資料會損壞嗎？

xGrid 的資料庫設定在「安全」和「速度」之間取了一個平衡點：不是每一次寫入都等磁碟確認（那太慢），而是在每個檢查點強制寫入磁碟。這樣即使中途斷電，最多損失最後一個檢查點之後的操作——不會損壞整個資料庫。

傳統資料庫的備份需要專用工具、特殊格式、和可能長達數分鐘的匯出過程。

嵌入式資料庫的備份就是複製一個檔案。

xGrid 的備份機制會：

緊急撤離時，甚至可以一鍵把整個資料庫打包帶走。因為資料庫就是一個檔案，「帶走所有資料」就跟「複製一個檔案」一樣簡單。

一台 xGrid 邊緣裝置能處理多少？

對於災難醫療的規模——每個站點通常 100–300 位病患/天——這個容量綽綽有餘。

在災難現場，最可靠的系統不是功能最強的，而是移動零件最少的。