根據(jù)數(shù)據(jù)庫設(shè)計的第三方式，在數(shù)據(jù)庫設(shè)計過程中，應(yīng)該盡量消除冗余。即設(shè)計數(shù)據(jù)庫時，某一個字段屬于一張表，但它同時出現(xiàn)在另一個或多個表，且完全等同于它在其本來所屬表的意義表示，那么這個字段就是一個冗余字段。

隨著企業(yè)數(shù)據(jù)量與并發(fā)量不斷的增加，冗余字段的存在到底是好還是壞呢？
根據(jù)第三范式而言，冗余字段是垃圾的數(shù)據(jù)庫設(shè)計。

2、舉例說明與研究

所有問題出現(xiàn)必然因為場景問題，針對冗余字段問題，分為兩個場景：

（1）快照場景（副本場景）：交易場景大部分是數(shù)據(jù)快照，而不是冗余，用戶下單時候的用戶名、地址、商品名稱、商品描述等，若采用關(guān)聯(lián)，商品在下單后發(fā)生了更新的話再去關(guān)聯(lián)查詢就會導(dǎo)致和用戶操作時的數(shù)據(jù)不一致，從而產(chǎn)生糾紛。

（2）冗余場景：一般數(shù)據(jù)改動的可能性少，而查詢多的場景會使用冗余，例如淘寶的店鋪名稱，淘寶商家中心會有這個字段，可能里面的商家論壇也有，再假設(shè)聚劃算這種獨立的大業(yè)務(wù)自己也存一份，再來個垂直頻道電器城的后臺管理也獨立存一份，這種場景是由于對查詢性能要求高產(chǎn)生的，所以必須要冗余，在業(yè)務(wù)的取舍上，肯定是對讓用戶更快看到信息，那么不可避免的是帶來維護成本的增加，對于數(shù)據(jù)一致性問題，只要做到最終一致就可以了，分布式的CAP原則的實際應(yīng)用基本都是通過犧牲數(shù)據(jù)一致性(C)來保證高可用(A)和高可靠(P)， 因為這種場景大部分都是可以接受短暫的數(shù)據(jù)不一致的，對業(yè)務(wù)的影響及其微小。

又比如，”用戶昵稱”字段”nickname”本來屬于表”user”，那么，表示”用戶昵稱”的字段就唯一的只應(yīng)該屬于”user”表的”nickname”字段，這樣，當(dāng)用戶要修改昵稱的時候，程序就只需要修改 user.nickname這個字段就行了。不過問題也隨之而來，我在其他數(shù)據(jù)表(如訂單orders表)里只存儲了用戶的ID，我要通過這個ID值得到用戶昵稱該怎么辦呢？一個普遍的解決方法是通過聯(lián)接(join)，在查詢時，通過id這個唯一條件聯(lián)接兩個表，從而取到用戶的昵稱。

這樣確實是沒問題，我也一直覺得這樣是最好的方案，擴展方便，當(dāng)要更新用戶信息時，程序中要修改的地方很少，但是隨著數(shù)據(jù)庫里數(shù)據(jù)不斷增加，百萬，千萬，同時，用戶表的數(shù)據(jù)肯定也在不斷的增加的，它可能是十萬，百萬。這個時候，你會發(fā)現(xiàn)兩個表通過聯(lián)接來取數(shù)據(jù)就顯得相當(dāng)費力了，可能你只需要取一個nickname這個用戶昵稱屬性，你就不得不去聯(lián)一下那個已經(jīng)幾十萬的用戶表進(jìn)行檢索，其速度可想而知了。

這個時候，你可以嘗試把nickname這個字段加到orders這個訂單表中，這樣做的好事是，當(dāng)你要通過訂單表呈現(xiàn)一個訂單列表時，涉及用戶的部分可能就不需要再進(jìn)行聯(lián)接查詢了。當(dāng)然，有利就有弊，這樣做的弊端就是，當(dāng)你嘗試更新用戶信息時，你必須記得用戶信息表里當(dāng)前被更新的字段中，有哪些是冗余字段，分別屬于哪些表，找到他們，然后加入到你的更新程序段中來。這個是程序中的開銷，開銷在開發(fā)人員的時間上了。至于這樣做是否值得，就得看具體情況而定了。

所以，目前要創(chuàng)建一個關(guān)系型數(shù)據(jù)庫設(shè)計，我們有兩種選擇：

1，盡量遵循范式理論的規(guī)約，盡可能少的冗余字段，讓數(shù)據(jù)庫設(shè)計看起來精致、優(yōu)雅、讓人心醉。

2，合理的加入冗余字段這個潤滑劑，減少join，讓數(shù)據(jù)庫執(zhí)行性能更高更快。

選擇哪一種呢？如果你是一個美學(xué)狂人，并且財大氣粗，非要使用第一種方案，也沒關(guān)系，這種方案的短板并非不可救藥的。比如，你可以增加服務(wù)器，從數(shù)據(jù)庫集群入手，進(jìn)行讀寫分離，讀的時候可以將壓力分散到不同的數(shù)據(jù)庫服務(wù)器上，這樣也可以獲得很好的性能，只是多付出了硬件成本和維護成本。或者，你可以在數(shù)據(jù)庫前端架設(shè)Memcached之類的緩存服務(wù)，減少讀寫數(shù)據(jù)庫的次數(shù)，也可以達(dá)到同樣的效果。問題在于你確定你需要緩存之類的東西。

如果做不到上面的只能選擇第二種了，當(dāng)涉及到修改的時候就需要將所有相關(guān)的數(shù)據(jù)進(jìn)行修改了。

原文：https://blog.csdn.net/ztchun/article/details/80034764?utm_source=copy

總結(jié)

以上是生活随笔為你收集整理的数据库冗余字段思考的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。