數據庫設計之冗餘字段設計

在設計數據庫時，某一字段屬於一個表，但它又同時出如今另外一個或多個表，且徹底等同於它在其原本所屬表的意義表示，那麼這個字段就是一個冗餘字段。

——以上是我本身給出的定義

 

冗餘字段的存在究竟是好仍是壞呢（

冗餘是爲了效率，減小join。單表查詢比關聯查詢速度要快。
某個訪問頻繁的字段能夠冗餘存放在兩張表裏，不用關聯了。

 

）？這是一個很差說的問題。可能在有人看來，這是一個很蹩腳的數據庫設計。由於在數據庫設計領域，有一個被你們奉爲圭臬的數據庫設計範式，這個範式理論上要求數據庫設計邏輯清晰、關係明確，好比，」用戶暱稱」字段」nickname」原本屬於表」user」，那麼，表示」用戶暱稱」的字段就惟一的只應該屬於」user」表的」nickname」字段，這樣，當用戶要修改暱稱的時候，程序就只須要修改 user.nickname這個字段就好了，瞧，很方便。不過問題也隨之而來，我在其餘數據表(如訂單orders表)裏只存儲了用戶的ID，我要經過這個ID值獲得用戶暱稱該怎麼辦呢？一個廣泛的解決方法是經過聯接(join)，在查詢時，經過id這個惟一條件聯接兩個表，從而取到用戶的暱稱。

這樣確實是沒問題，我也一直以爲這樣是最好的方案，擴展方便，當要更新用戶信息時，程序中要修改的地方不多，可是隨着數據庫裏數據不斷增長，百萬，千萬，同時，用戶表的數據確定也在不斷的增長的，它多是十萬，百萬。這個時候，你會發現兩個表經過聯接來取數據就顯得至關費力了，可能你只須要取一個nickname這個用戶暱稱屬性，你就不得不去聯一下那個已經幾十萬的用戶表進行檢索，其速度可想而知了。

這個時候，你能夠嘗試把nickname這個字段加到orders這個訂單表中，這樣作的好事是，當你要經過訂單表呈現一個訂單列表時，涉及用戶的部分可能就不須要再進行聯接查詢了(變成了單表查詢)。固然，有利就有弊，這樣作的弊端就是，當你嘗試更新用戶信息時，你必須記得用戶信息表裏當前被更新的字段中，有哪些是冗餘字段，分別屬於哪些表，找到他們，而後加入到你的更新程序段中來。這個是程序中的開銷，開銷在開發人員的時間上了。至於這樣作是否值得，就得看具體狀況而定了。

因此，目前要建立一個關係型數據庫設計，咱們有兩種選擇：

1. 儘可能遵循範式理論的規約，儘量少的冗餘字段，讓數據庫設計看起來精緻、優雅、讓人心醉。
2. 合理的加入冗餘字段這個潤滑劑，減小join，讓數據庫執行性能更高更快。

選擇哪種呢？若是你是一個美學狂人，而且財大氣粗，非要使用第一種方案，也不要緊，這種方案的短板並不是不可救藥的。好比，你能夠增長服務器，從數據庫集羣入手，進行讀寫分離，讀的時候能夠將壓力分散到不一樣的數據庫服務器上，這樣也能夠得到很好的性能，只是多付出了硬件成本和維護成本。或者，你能夠在數據庫前端架設Memcached之類的緩存服務，減小讀寫數據庫的次數，也能夠達到一樣的效果。問題在於你肯定你須要緩存之類的東西。

 

轉載於：http://blog.sina.com.cn/u/3232608592