開發環境架構底定後，接下來的設計或規畫也比較能夠固定下來，當然最好是能把開發環境直接架起來，這樣在思考設計的過程也能夠直接簡單的驗證思考的方向是否正確，並且可以隨時調整開發環境。接下來就由資料庫的規畫開始。
考量到小白未來在搜尋及應用上可以即時的取得分析結果，以及大量資料的搜尋問題等，那資料庫的設計盡量達到以下幾個點，
- 不要太複雜及關聯太多資料表(Table)，這樣可以提高未來查詢效能。
- 資料分流，目前個股、ETF集權証等，大約有10000隻，如果全部放一個檔案可能會造成資料庫查詢效能緩慢問題，而且資料庫還是有一些容量上限問題，一般是幾TB，但還是想辦法分流，是比較好，小白的分流方式是一個個股，就自動建立一個資料表(table)，這樣應該可以有效的達到分流及提高效能的目標。
- 資料欄位(Field)，規劃上是希望在查詢個股資料時，就可以把每天分析的結果一併找出來，因此在每日的資料表上，就保留分析結果及其他常規計算的欄位，讓每日分析後的結果存放，缺點就是每一筆資料的欄位數會變得許多，沒結構化，但這問題倒不用在意，設計的目的在於平衡，而不在炫技。
有了這3個概念想法後，大部分資料寫入資料庫前或後，會即時或直接進行分析跟複雜的計算，更新資料庫裡的分析、均量價等欄位，以下就是設計的資料格式(Table Schema)。
我們定義了三個資料表(Table)，關聯性並不複雜，但實際上比較複雜會落在第三個資料表-StockDaliy，因為他要負責做分流的工作，我的做法是這個資料表由程式自動產生，只要有新的個股在蒐集資料時發現，就產生一個StockDaliy，資料表的格式就會變成”StockDaliy_” + {Stock id}，基本上是對應Stock這個資料表的，當然之後如果StockDaliy要增減欄位(Field)，那就必須要寫一隻程式做批次修改，但這應該是可以接受的範圍。
因此未來每日蒐集完資料料就要同時更新Stock及StockDaliy，一個是記錄最近的記錄，另一個則是記錄每天的資訊，當分析完資料後，也是用同一個邏輯來記錄。
在StockDaliy上有一個type的欄位，這個欄位用來記錄該筆記錄是每日、每周、每月、每季等總合記錄，因此在蒐集資料的同時，也會順便算出周、月、季等統計型的資料並放入StockDaliy，未來想要查詢周、月、季，就依type查詢即可。
未來如果要繼續增加個股資料時，可以以Stock這個資料表為主關聯，並往外延伸，如除權息、EPS、營利等資訊，另外大盤指數、類股指數目前也是定義在Stock 資料表 裡面，透過Category這個資料表來做分辨，好處是以後除了分析個股外，也可以一併分析大盤指數跟類股指數，那程式設計起來也相對單純，並且可重複利用，也許只要調整一下參數就可以搞定。