Re: [閒聊] mySQL大師請進

作者: eight0 (欸XD)   2022-07-14 12:27:45
> 要每頁都點進去看產品編號
不懂什麼意思
> 如果統一用一個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,前端要調舊資料時甚至可以直接跳過資料庫。
作者: an94mod0 (an94mod0)   2022-07-14 12:29:00
大師
作者: MurasakiSion (紫咲シオン)   2022-07-14 12:30:00
大師
作者: Apache (阿帕契)   2022-07-14 12:31:00
big query
作者: YukihanaLami (lami snowflake)   2022-07-14 12:52:00
大師
作者: JenniferLope (ㄚ)   2022-07-14 12:54:00
大師

Links booklink

Contact Us: admin [ a t ] ucptt.com