Python 加 Google Sheet？輕量級會員管理系統試做！

目錄

• 相關連結
• 需求確認
• 技術選型
• 資料庫
• 資料表
• 系統功能
• 服務部署
• 結語

相關連結

• GitHub
• Streamlit（試用）

專案起因

甫結束轉職培訓班的課程不久，一位經營獨立健身工作室的朋友得知我在學習程式開發，便詢問是否能協助開發一套內部使用的會員管理系統。在評估過對方的需求與我目前的能力後，認為這是一個不錯的實戰機會，於是便開啟了這個輕量化會員管理系統的專案。

需求確認

本專案屬於客製化委託，因此所有的技術選擇與開發方向皆需緊扣客戶（對方）的需求。以下為客戶的背景與具體需求：

1. 無技術背景：團隊內無技術開發人員，原先僅使用 Excel 或雲端試算表進行紀錄。
2. 內部使用：系統僅供員工內部紀錄，不對外開放給會員使用。
3. 核心功能：需包含會員登記、交易行為記錄、金額結算等基本功能。
4. 低維運成本：屬於試驗性質的專案，維運方面並無多餘預算。

技術選型

基於上述需求，我為專案規劃了以下的基本架構：

1. 後端：Python

   • 我目前最熟悉的程式語言，擁有豐富的套件支援。

2. 資料庫：Excel 或 Google Sheet

   • 這是客戶團隊最熟悉的工具。即便系統發生意外，他們仍能直接開啟檔案進行編輯與修正。
   • 操作彈性：即使因操作失誤導致系統報錯，客戶也能手動修正資料，保持營運彈性。
   • 合適優於完美：作為資料工程人員，我深知試算表並非正規的資料庫。但考量客戶缺乏 SQL 操作能力，選擇正規資料庫反而可能因技術門檻造成額外困擾。在此情境下，選擇合適的工具比追求技術上的完美更為恰當。

3. 前端：Streamlit

   • 目前最輕量、易於開發與部署的 Python 前端框架。作為內部工具，其功能與介面質感已相當足夠。

4. 部署：地端或低價（免費）雲端平台

   • 考量客戶幾無維運預算，且應用場景多為上班時間的辦公室環境，將系統建置於地端或免費的雲端服務（PaaS）是較合理的選擇。

資料庫

雖然透過 Python 程式能靈活地調整功能，但資料庫作為系統的核心，承載了客戶最重要的資產。因此，資料庫的建置與規劃應在初期就定案，避免後續修改牽一髮而動全身，增加維護成本。

地端資料庫

由於客戶習慣使用 Excel 記錄，開發初期我優先採用地端檔案作為資料庫。針對此專案性質，地端部署有其合理性：

• 使用時間固定：僅在營業時間使用，無需 24 小時運作。
• 安全性考量：因無專職人員維護，非使用時間關閉資料庫，反而能物理性地避免未授權的修改。

我採用以下邏輯建立資料庫連線：

1. 在專案目錄中建立 Excel 檔，並設定檔名。
2. 將檔名設為全域常數，透過函式在專案目錄中搜尋，進行路徑定位。
3. 取得絕對路徑後讀取檔案。

Fitness-Studio-Member-System/
├── codes/                 # 集中存放程式碼
│   ├── mod/               # 存放模組化程式
│   └── main.py            # 測試用主程式
├── database.xlsx          # 地端資料庫 (Excel 檔案)
├── streamlit_app.py       # Streamlit 主程式入口
├── requirements.txt       # 專案依賴套件清單
└── README.md              # 專案說明文件

此設計的考量點在於：

• 彈性：檔名可任意修改，僅需調整常數即可重新連線。
• 可攜性：解決路徑不固定的問題。只要 Excel 檔與專案位於同一目錄下，系統即可自動定位並讀取，方便部署至客戶的電腦。

雲端資料庫

在初步建立地端版本並與客戶討論流程時，對方提到團隊另有一個共用的 Google Sheet，並詢問是否能將兩者結合，以利統一管理並省去手動同步的麻煩。

所幸 Google Sheet 與 Excel 高度相容，對 Python Pandas 而言操作差異不大，僅需調整連線方式：

1. 建立 GCP 專案，啟用 Google Sheet API 服務。
2. 建立服務帳戶（Service Account）授予權限，並下載憑證檔（JSON）。
3. 將 Google Sheet 的編輯權限共享給該服務帳戶的 Email。
4. 透過 Google 官方套件與憑證，即可讀取、寫入該雲端試算表。

由於 Google Sheet 的 URL 固定，只要權限設定正確，無論專案部署於何處皆能連線，反而省去了地端路徑定位的流程。

資料表

資料表的設計完全依據客戶的業務邏輯訂製。我採用了部分關聯式資料庫（RDB）的設計思維，結構如下：

• Database：對應 Excel 檔或 Google Sheet 本體。
• Table：對應試算表中的各個分頁（Sheet）。

以下為各資料表（分頁）的功能定義：

• A_main：結算表。用於表列每位會員的最終結算結果（剩餘堂數、金額等）。
• B_event：交易紀錄表（流水帳）。存放所有購買或消費紀錄。對此表進行資料聚合（Group by / Aggregation）運算後，即為 A_main 的內容。
• C_member：會員資料表。紀錄所有會員的基本資料（ID、姓名、電話等）。
• menu：產品價目表。紀錄產品項目與單價，供系統在交易時查詢。
• coach：教練名單。紀錄內部操作人員（教練）名單。

系統功能

由於系統定位為內部記錄使用，不涉及外部會員註冊、金流串接等複雜邏輯，因此功能設計上相對單純直接。

新增會員

• 提供輸入會員基本資料及備註。
• 資料驗證：

1. 會員編號：作為 Primary Key，系統會檢查是否唯一且不重複。
2. 電話：使用 Regex（正規表示式）進行驗證，僅允許符合台灣市話或手機格式的輸入。
3. 生日及教練：使用選單（Selectbox）規範輸入內容，避免格式錯誤。

購買課程

• 需先建立會員資料方可進行購買。
• 會員選擇：使用 st.multiselect 支援搜尋與多選，提升操作效率。
• 自動計算：教練、方案、堂數皆連動資料庫中的 menu 與 coach 表，系統會自動計算總金額。
• 付款資訊：若選擇匯款，系統強制要求填寫帳號末五碼以利查帳。
• 客製方案：除了一般課程，亦保留「特殊課程」功能，允許手動輸入單價與堂數，保留議價與客製化的彈性。

上課扣堂

• 批次操作：透過 st.multiselect 可一次選取多位會員（適用於團體課程場景）。
• 邏輯驗證：系統會自動檢查選取的會員是否擁有該方案的「剩餘堂數」。若無購買紀錄或堂數已歸零，系統將拒絕執行並跳出警示。

會員退款

• 針對退款需求，系統設計了自動結清功能。
• 系統會抓取該會員目前的剩餘堂數，並新增一筆「退款」屬性的交易紀錄，將堂數一次扣除（歸零），結算後該會員帳戶即回復初始狀態。

其他功能

除了核心交易功能外，為了提升管理效率與顧客關係，我也加入了一些輔助功能。

1. 管理員權限

• 客戶希望在管理層操作時能看到詳細數據，但一般教練操作時則隱藏。
• 設計了簡易的權限機制，需在首頁輸入正確密碼才能切換至「管理員模式」，解鎖即時資料查看功能。（下圖資料皆為虛構測試資料）

2. 當月壽星

為協助客戶維繫顧客關係，系統會自動篩選並列出當月生日的會員，以及其近期的交易活躍度，方便安排行銷活動或給予祝福。

3. 手動更新

考量到資料庫（Google Sheet）可能被直接編輯，系統設計了「手動更新」按鈕。當使用者繞過系統直接修改試算表時，點擊此按鈕可強迫系統重新快取資料，確保顯示內容正確。

服務部署

• 初期構想：起初使用地端 Excel 時，我曾考慮將 Python 環境與套件打包為可攜式（Portable）版本，以免去在客戶電腦安裝環境的繁瑣流程。
• 最終方案：隨著資料庫轉移至 Google Sheet，且考量系統負載量不高，我最終選擇部署於免費的 Streamlit Cloud。
• 休眠機制：免費版服務在閒置過久後會進入休眠，重新啟動（Cold Start）需等待一小段時間。
• 資料安全：由於資料實體儲存於 Google Drive，即使 Streamlit 服務重啟或更新，資料也不會遺失。
• 效能表現：讀寫資料皆需透過 API 與 Google Sheet 溝通，速度雖不如地端資料庫，但作為內部行政系統，其延遲在可接受範圍內。

結語

作為新手工程師，起初對於承接 B2B 的商業專案感到些許卻步。因為我深知當開發與商業需求掛鉤時，就不僅是寫程式這麼簡單，還必須考量商業規範、責任歸屬及後續維護等議題。作為個人開發者，面對企業客戶時，我自認在經驗上或許還不足以完全承擔這些責任。

所幸這次專案性質屬於試驗性嘗試，讓我在風險相對可控的情境下執行。我也在專案啟動之初，便將費用、功能邊界及售後服務範圍溝通清楚，避免日後產生糾紛。

對我而言，這是一次非常寶貴的實戰經驗。將所學的資料工程知識應用於後端開發，打造出真實可用的系統，不僅驗證了自己的能力，也讓我看見程式技術在解決實際問題上的無限可能。雖然目前的實作手法尚顯粗糙，距離專業的後端架構仍有學習空間，但這一步已讓我充滿信心。