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