> 要每页都点进去看产品编号
不懂什么意思
> 如果统一用一个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，前端要调旧资料时甚至可以直接跳过数据库。

大师

大师

big query

大师

大师