> 要每頁都點進去看產品編號
不懂什麼意思
> 如果統一用一個table
> 全部商品爬到資料放一起
> 久了感覺會越來越膨脹
> 搜尋速度會下降？
這是實際發生過的事嗎？
如果不是，你可以等實際發生後再把表格切成10份
（不過那時可能有更好的解法）
不用在這時候煩惱
現在考慮這些事情︰
* 開發速度 下降
* 程式邏輯複雜度 增加
* 表格維護難度 增加
* 效能 不知道 沒證據 感覺會增加
沒有必要
> https://i.imgur.com/uWM2LA1.png
如果是我的話
1. 不要用外部資料做key，因為不知道對方會不會改。現在是int(6)，
一個月後還是嗎？
可以做一個 internal_id <-> product_id 的表，用內部 id 作為真的 key。
這樣對方有什麼改變，都很容易修正。
不在意 permission 的話，也可以直接在 main 裡設置一個 incremental 內部id。
2. 不需要把 timeline 的表格切成好幾份，把對應的 key / composite key （時間？）
做好即可。
> 我那個productid1跟2是照教授那個建議
> 找ID尾數10個表
不清楚討論的過程，所以不評論。
但資料庫的速度問題，大部份是 index 跟 query 做得太爛，甚至是完全沒做。
如果真的遇到資料庫肥大的問題，更常見的做法是按時間把資料 archive 進靜態檔案。
因為這些 timeline 資料都是不會改變的，不需要做交易，沒有必要一直放在資料庫裡。
可以把上一季產品的資料 archive，前端要調舊資料時甚至可以直接跳過資料庫。