第三代理財系統

對於持之以恆的理財愛好者而言，心中大抵都有一套駕輕就熟的記帳心得。時光荏苒，小弟不遺餘力獨立開發的 《Simple Money Keeper 2》 (以下簡稱 SMK2）轉眼已有數年光景。在這段日子裡，系統歷經無數次的除錯、優化與版本更新，從最初不夠穩定，到如今已臻成熟。

在此由衷感謝各位因緣際會選用本系統，你們慷慨解囊的隨心贊助，正是我持續優化的底氣。特別是兩位在開發路上與我交流密切的朋友，他們從十年前的第一代原型便一路並肩同行、沿用至今；這份毫無保留的肯定與信任，於我而言，正是最珍貴的推動力 😊

近日，我心中又悄然萌生了創作 《Simple Money Keeper 3》 (以下簡稱 SMK3) 的強烈念頭。這並非一時的心血來潮，事實上，在過去日子裡不定期為二代系統進行維護與除錯的過程中，我愈發意識到，其底層架構與使用體驗，依然存在著不少改善空間；與其抱殘守缺，不如打破現有的掣肘，推倒重來，開啟第三代的革新計劃 😎

現時 SIMPLE MONEY KEEPER 2 主頁介面

談及 SMK3 的創作，最關鍵的蛻變，莫過於資料庫的全面轉型。考量到兩者的語法架構大同小異，基本上無需重新摸索一套新語言，我便順理成章地決定採用 SQLite 作為主力資料儲存庫，正式告別以往依賴的 SQLce。

回溯歷史，SQLce 作為微軟 2000 年代的產物，當年的歷史使命，主要是為早期的行動通訊與智慧型手機市場提供數據儲存方案。若在現今的視窗環境下運行，用家必須先安裝相關的 Runtime (包含 x86 與 x64 版本) 方能順利運行 SMK2 軟件；這種環境依賴，無形中造成了使用上的諸多不便。反之，SQLite 得益於優秀的輕量化架構，用家不需要在電腦中塞入任何額外的運行庫，直接雙擊執行檔便能運行自如、乾淨俐落。

除了部署上的便利，兩者在容量規格上更是有著天壤之別。昔日 SQLce 的預設容量上限僅為 256MB，縱使能透過修改 Max Database Size 參數勉強增大，其硬性終極上限也依然被鎖死在 4GB，一旦超越這道紅線，資料庫便會直接崩潰報錯。然而 ，SQLite 架構專為大數據吞吐而生，單個資料庫理論上限高達 140 TB！對於家庭式的系統應用而言，這無異於毫無限制。

另一個核心問題，便是兩者在運行速度與效能表現上的懸殊，更是促使我非換不可的決定性因素。

一套需要頻繁讀寫、統計分析的理財系統，資料庫的反應速度直接決定了用戶的操作體驗。昔日的 SQLce 畢竟是二十年前的舊架構，在處理複雜的條件查詢或多表關聯時，效能難免顯得有些吃力。特別是當記帳數據日積月累、資料庫逐漸增大後，每次開啟數據龐大的報表或進行年度統計，系統總會需要少許時間去讀寫，缺乏流暢感。

反觀 SQLite，其內部演算法經過了長期的優化，記憶體管理與磁碟讀寫的效率極高。在測試環境下，無論是數萬筆帳目資料的瞬間載入，還是複雜的多筆資料交叉比對，SQLite 都能在極短的時間內處理完畢；這種速度上的飛躍，絕非昔日的 SQLce 所能媲美。

關於開發 SMK3 的核心骨幹，小弟依然選擇 Visual Basic 編寫語言。無可否認，在當今的開發浪潮中，主流技術大多已轉向 C#、TypeScript 或 Python 等熱門語言，VB 逐漸淡出了大眾視線。然而，我始終覺得它是一套極其優秀且直觀的開發工具，而且，它亦是我當初自學的啟蒙語言。或許，正因如此，我特別希望為自己保留幾套純粹由 VB 打造的作品，讓這份創作情懷延續下去。

至於目前的開發進度，現階段我只草擬了第三代的設計藍圖。另外，我亦考慮將二代部份成熟的核心資源與介面邏輯，直接移植到第三代中繼續沿用。這樣一來，現有用戶在使用新系統後，依然能保持那份熟悉的操作感，不需要重新適應。

坦白說，距離 SMK3 的面世確實言之尚早。畢竟在日常生活中仍有許多工作需要優先處理，小弟只能利用十分有限的餘暇時間來推進進度。這也意味著，新系統的開發將會是一場考驗耐性的持久戰 😪

昔日 SIMPLE MONEY KEEPER 2 的軟件簡介

按此進入