一開始只是想記錄一些訂單資料。

反正 Google Sheet 免費、大家都會用、不用建環境、手機也能開——先用這個頂著，等之後有預算再說。

這句話，幾乎每個後來找我的客戶都說過。

從「夠用」到「開始出事」

剛開始真的很香。

一個 Sheet 記訂單、一個 Sheet 記客戶、一個 Sheet 記庫存。用 VLOOKUP 把資料串起來，主管要看數字就開 Sheet，業務要更新狀態就打開改，簡單、直覺、零成本。

但是，有一天你打開那個 Sheet，發現它在轉圈圈。

等了幾秒，它終於開了，但滾輪滾下去，又開始卡。你試著在某個欄位打字，它停頓了一下，才把你打的字顯示出來。你跟旁邊的同事說，他也說他那邊很慢。你重新整理，好一點，但過五分鐘又回來了。

這時候，你已經有幾千筆資料了。

然後開始發生各種事

有人不小心動到公式。

不是故意的。可能是要複製貼上，結果選錯了範圍；可能是在手機上操作，手滑碰到了什麼。總之，某一欄的 VLOOKUP 壞了，然後依賴那欄的所有計算全部跟著壞，你花了一個下午才找到哪裡出問題。

之後你開始鎖定那些關鍵欄位，但 Google Sheet 的權限管理很難做到精細，你要嘛讓人家能編輯、要嘛完全鎖死，沒有中間地帶。

同時有人在裡面，就開始打架。

兩個人同時編輯，有時候會看到對方的游標在跑，感覺還好。但偶爾你存完之後，發現你剛才改的東西不見了，或是跟對方的修改撞在一起，變成一個奇怪的混合版本。

這種事，往往要等到出貨錯了、帳對不上、客戶投訴了，才發現資料早就亂了。

然後你開始用 Google Sheets API。

因為你想寫個小程式，自動把表單填寫的資料寫進 Sheet，或是定時抓資料出來算報表。你照著文件串接，OAuth 驗證搞了一個下午，終於跑起來了，覺得還不錯。

但是，API 有請求頻率限制。你的資料一多、呼叫一頻繁，開始收到 429 Too Many Requests。你加了 retry 邏輯，好一點，但還是不穩定。有時候跑到一半，整個中斷，你不知道資料有沒有寫進去，只能手動去 Sheet 裡確認。

這時候，你已經在維護一個比「不用 API」更複雜的系統了。

於是你開始「分表」

這是幾乎所有人都會走到的那一步。

資料太多、一個 Sheet 太慢？那就拆成多個 Sheet，按月份、按類型、按地區，各放一個。這樣每個 Sheet 資料量少一點，讀取快一點。

這個方法有效，但只有一陣子。

因為現在你要查一筆資料，你得先知道它在哪個 Sheet；你要做跨表統計，要寫更複雜的 IMPORTRANGE 公式；你要讓新人上手，要先解釋你們的分表邏輯……

而且你心裡很清楚：這只是在延後問題，不是在解決問題。

問題的核心，是 Google Sheet 根本不是資料庫

Google Sheet 是試算表，是為了讓人「看資料」設計的，不是為了讓程式「存取資料」設計的。

真正的資料庫，查詢一萬筆資料不會慢、同時一百個人寫入不會衝突、某一筆壞掉不會拖垮全部、有完整的權限控制可以說「這個人只能看這些欄位」。

這些，Google Sheet 都做不到——不是因為它爛，而是因為它根本不是為了這些場景設計的。

你用它撐到現在，已經很厲害了。但它能給你的，就是這樣了。

那什麼時候該換掉它？

不用等到「整個掛掉」才決定。如果你現在有這些狀況，就是時候認真考慮了：

• Sheet 開啟或滾動明顯感覺到卡頓
• 需要靠「分表」或「封存」來管理資料量
• 曾經因為有人誤改而花時間修資料
• 開始串 API，但遇到頻率限制或不穩定
• 不同部門的資料要靠人工搬來搬去才能對到

這不是「技術問題」，是「業務規模長大了，工具也該跟著升級」。

換掉不代表一切重來

很多人一聽到「建資料庫」就覺得複雜、昂貴、要花很長時間。

但實際上，如果只是要把 Google Sheet 的核心功能搬到一個穩定的系統，通常沒有想像中那麼大的工程。你現有的資料可以匯入、你現在的流程可以保留、介面可以做得比 Sheet 更直覺——而且終於不用再擔心「有人動到公式整個壞掉」這件事。

Google Sheet 是一個很好的起點。但它的終點，就是你現在遇到的這些。

如果你也走到這個階段，歡迎找我聊聊，說不定比你想的更快解決。
原文