問題描述下面是兩張數據表：分別為 order,user。表關系 order.user_id 關聯 user.id。設計一個場景：在后臺管理中，我們需要進行訂單搜索，如：根據時間、用戶名進行搜索。一：以前的做法是只在 order 表中存入 user.id,通過 order.user_id 表明表關系。然后在程序中進行關聯搜索。二：現在的想法如上面的圖示：將 user.username 一并存入 order 中。這樣做的想法是方便搜索，減少表的關聯問題1：兩種做法那種好，或者不同優點或缺點。2：在第二種做法中，存在一個問題，如果用戶修改了 username。那么 order 中的字段必須相應修改。如何處理更好？我目前的想法是：一個是在用戶修改用戶名時，去修改相應 order 中的 username。第二種使用觸發器(未實踐)。謝謝！
2 回答
四季花海
TA貢獻1811條經驗 獲得超5個贊
數據量不大的時候可以考慮只保存關聯字段
數據量大的話可以考慮數據適當冗余，就order而言，其實username改動的頻率比較小，呈現有差異的概率比較小，對不影響關鍵數據把，我認為也可以不用同步，或很長一段時間定時去同步
森林海
TA貢獻2011條經驗 獲得超2個贊
如果數據量大，訪問量大，建議上elasticsearch之類的專業的搜索工具。
如果數據量不大，訪問量一般般，你不用elasticsearch，那么只是用mysql。建議遵循范式設計。
如何設計？我認為分為3個表是最好的。
1、訂單表
2、用戶表
3、訂單用戶搜索關系表。
其實表3的作用跟elasticsearch作用一樣的。3表其實是存儲冗余數據，以空間換時間。
如何解決username改動造成的影響，username改動，表3的數據需要進行更新即可。
一個username能對應幾個訂單，幾百個？幾千個？幾萬個？我認為不多。最多幾萬個。而且username更新頻率多大？一天？一個月？
這樣想下來，其實username每次改動更新表3不是什么麻煩事。
其實你把冗余數據放到表1也是可以的。但我認為訂單就是訂單、用戶就是用戶。保持他們的獨立性，日后你擴展就很容易了。
試想一下，假如以后你們公司做大了，老板需要你用elasticsearch來解決搜索的問題，你把冗余數據存儲到了表1，等于這部分的冗余數據其實沒有用處了。
但如果我把這部分的冗余數據存儲到了表3，我大可直接刪除表3即可。對業務絲毫無影響，也不會產生垃圾數據。
添加回答
舉報
0/150
提交
取消