資料庫與持久化¶

本專案目前使用 SQLAlchemy，支援：

SQLite
PostgreSQL

但 migration 並不是 Alembic，而是由程式在啟動時自行補 schema。

DB 選項¶

SQLite¶

預設使用 SQLite。

相關設定：

DB_TYPE=sqlite
SQLITE_PATH=./training_params.db

適合：

本機開發
單機研究
輕量原型

PostgreSQL¶

若要正式部署，建議切 PostgreSQL。

DB_TYPE=postgresql
DATABASE_URL=postgresql+psycopg2://USER:PASSWORD@HOST:PORT/DBNAME

適合：

多 worker
多實例
正式環境
長期保存與備份

ORM 表¶

目前主要表包含：

training_param_ranges
trading_notes
strategy_params
backtest_segments
optimization_tasks
optimization_saved_results

`strategy_params`¶

這是策略參數的核心表。

目前邏輯上是：

每個 (ticker, timeframe_minutes, strategy_name) 一份參數

也就是說：

同商品、同週期、不同策略，不共用參數

`optimization_tasks`¶

最佳化任務表，保存：

任務條件
狀態
進度
strategy_name
結果列表

由於 results 可能很大，所以後端已做 API 輕量化，不代表 DB 內沒有完整保存。

`training_param_ranges`¶

人工標記的參數訓練區間，包含：

時間範圍
對應參數
顏色
備註

`trading_notes`¶

人工備註系統，主要依：

ticker
timeframe_minutes
params_hash

做群組關聯。

migration 現況¶

目前流程大致是：

create_all
_run_migrations()
若發現少欄位就做 ALTER TABLE 或 SQLite 重建表

目前已看到的 migration 內容¶

optimization_tasks.strategy_name
strategy_params.strategy_name
strategy_params 的唯一鍵更新為含 strategy_name

為什麼這是風險¶

這種 migration 方式的優點是：

快
上手容易
無需額外 migration 工具

缺點是：

無版本紀錄
多人協作時容易漂移
正式環境變更追蹤困難
SQLite / PostgreSQL 要分開處理細節

如果要正式化，建議¶

短期¶

先把 schema 說明寫清楚
在部署文件中明說 migration 由程式啟動自動處理

中期¶

引入 Alembic
把所有 schema 變更版本化
部署流程中顯式執行 migration

其他持久化形式¶

除了 DB，本專案還有兩種持久化：

JSON 檔¶

backtest_history.json

記憶體 cache¶

CacheManager.cache
多區段回測 cache

因此你要理解：

並不是所有狀態都在 DB
一般回測結果目前仍 heavily 依賴 process 內記憶體

這對正式部署很重要，因為：

重啟服務後 cache 會消失
多實例之間 cache 不共享

重構方向建議¶

若目標是更可重建、更可部署：

把一般回測歷史與結果移入 DB
把 backtest_history.json 逐步淘汰
把記憶體 cache 視為加速層，而不是唯一來源
導入正式 migration 工具