鍍金池/ 問答/Java  PHP  C#  數(shù)據(jù)庫/ 數(shù)據(jù)庫做字段冗余好還是數(shù)據(jù)實時生成好?

數(shù)據(jù)庫做字段冗余好還是數(shù)據(jù)實時生成好?

有這樣一個需求:記錄一篇文章的收藏記錄。

所以需要有兩個表,一個是“文章表”,一個是“收藏記錄表”。
讀取該文章后需要讀取出該文章的收藏數(shù)量。

有兩種解決方案:
1.文章里有“收藏數(shù)量”字段,每當(dāng)一位用戶收藏該文章,就將該字段+1,同時往“收藏記錄表”中添加一條收藏記錄。
優(yōu)點是在讀取文章的時候,不需要聯(lián)表查詢它的收藏記錄;缺點是進(jìn)行收藏操作的時候需要寫兩張表,并且會多一個字段的冗余。

2.文章里沒有“收藏數(shù)量”字段,當(dāng)用戶收藏該文章,只會往“收藏記錄表”中添加一條收藏記錄。
優(yōu)點是,收藏的時候只需要寫一張表,而且沒有字段冗余;缺點是讀取的時候需要聯(lián)表查詢,可能效率也不是很高。

請問這兩個方案哪一個更好呢?

回答
編輯回答
下墜

主要看具體業(yè)務(wù)需求,不過更推薦方案一。

首先,字段的冗余并不是一個多大的缺點,另外,用事務(wù)來實現(xiàn)多表操作也很方便。

而方案一帶來的好處除了查詢效率高,最關(guān)鍵的是支持的業(yè)務(wù)場景更多,雖然現(xiàn)在看,收藏數(shù)好像也不是個重要字段,但是某天產(chǎn)品突然加需求說,咱們要按收藏數(shù)來個排序,分頁等各種,這時候用方案二實現(xiàn)起來就會越來越惡心

2018年1月9日 16:26
編輯回答
替身

如果列表需要顯示收藏數(shù)(廢話)。顯然方案二需要count查詢多次。收藏數(shù)量大了之后會消耗性能。所以建議方案一。方案一如果用事務(wù)用鎖(解決數(shù)量不一致?)。就太小題大做了。我覺得不需要用事務(wù),可能會導(dǎo)致數(shù)目與列表不一致。但是用戶會在乎這個嗎

2018年4月14日 23:49
編輯回答
半心人

常用字段的話建議用冗余

2017年9月21日 22:31
編輯回答
挽青絲

建議使用冗余,空間是不值錢的,效率是值錢的,真正的企業(yè)級數(shù)據(jù)庫里一定有數(shù)據(jù)冗余,沒有必要一定遵循數(shù)據(jù)庫設(shè)計的那幾大范式

2018年1月27日 13:36
編輯回答
不討囍

建議用方案一,同時配合使用redis,這個當(dāng)然要看網(wǎng)站的規(guī)模了,利用redis存儲文章的收藏量信息,需要更新收藏量信息時,先寫入redis,再定時寫數(shù)據(jù)庫

2018年2月16日 09:36
編輯回答
失心人

建議題主使用redisincr命令

  1. Redis incr 可以實現(xiàn)原子性的遞增,可應(yīng)用于高并發(fā)
  2. 利用緩存可緩解請求數(shù)據(jù)對數(shù)據(jù)庫的直接施壓
2017年6月29日 10:49
編輯回答
悶騷型

第一個吧,一個字段根本不占用什么空間。
事務(wù)還有鎖啥的,其實不必考慮。這個數(shù)又不是賬戶余額。錯幾個也沒什么大不了的嘛。

2018年1月5日 04:56
編輯回答
帥到炸

第一種方案缺點你也說了,所以這里不贅述了;補充下就是還會涉及到事務(wù)、鎖等。
第二種方案在某種程度上也行,但是如果用到count,收藏稍微頻繁點,mysql的count比較坑。
我的建議是你在第二種的基礎(chǔ)上分兩步:

  1. 獲取文章
  2. 獲取收藏數(shù)量

簡單的說就是不要把收藏數(shù)量和文檔放到一個接口,分開。
未來如果性能不好了加緩存也好加了。

2018年2月16日 00:02
編輯回答
失魂人

設(shè)計根據(jù)業(yè)務(wù)來吧,收藏數(shù)量這種業(yè)務(wù)根本不是特別重要,你放把收藏數(shù)放內(nèi)存里都可以,分布式的話放緩存里

2017年8月7日 20:45