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