資料庫設計之冗餘字段 感覺挺真實

2021-06-05 10:52:09 字數 1317 閱讀 9900

在設計資料庫時,某一字段屬於乙個表,但它又同時出現在另乙個或多個表,且完全等同於它在其本來所屬表的意義表示,那麼這個字段就是乙個冗餘字段。

——以上是我自己給出的定義

冗餘欄位的存在到底是好還是壞呢?這是乙個不好說的問題。可能在有人看來,這是乙個很蹩腳的資料庫設計。因為在資料庫設計領域,有乙個被大家奉為圭臬的資料庫設計正規化,這個正規化理論上要求資料庫設計邏輯清晰、關係明確,比如,」使用者暱稱」字段」nickname」本來屬於表」user」,那麼,表示」使用者暱稱」的字段就唯一的只應該屬於」user」表的」nickname」字段,這樣,當使用者要修改暱稱的時候,程式就只需要修改 user.nickname這個字段就行了,瞧,很方便。不過問題也隨之而來,我在其他資料表(如訂單orders表)裡只儲存了使用者的id,我要通過這個id值得到使用者暱稱該怎麼辦呢?乙個普遍的解決方法是通過聯接(join),在查詢時,通過id這個唯一條件聯接兩個表,從而取到使用者的暱稱。

這樣確實是沒問題,我也一直覺得這樣是最好的方案,擴充套件方便,當要更新使用者資訊時,程式中要修改的地方很少,但是隨著資料庫裡資料不斷增加,百萬,千萬,同時,使用者表的資料肯定也在不斷的增加的,它可能是十萬,百萬。這個時候,你會發現兩個表通過聯接來取資料就顯得相當費力了,可能你只需要取乙個nickname這個使用者暱稱屬性,你就不得不去聯一下那個已經幾十萬的使用者表進行檢索,其速度可想而知了。

這個時候,你可以嘗試把nickname這個欄位加到orders這個訂單表中,這樣做的好事是,當你要通過訂單表呈現乙個訂單列表時,涉及使用者的部分可能就不需要再進行聯接查詢了。當然,有利就有弊,這樣做的弊端就是,當你嘗試更新使用者資訊時,你必須記得使用者資訊表裡當前被更新的字段中,有哪些是冗餘字段,分別屬於哪些表,找到他們,然後加入到你的更新程式段中來。這個是程式中的開銷,開銷在開發人員的時間上了。至於這樣做是否值得,就得看具體情況而定了。

所以,目前要建立乙個關係型資料庫設計,我們有兩種選擇:

盡量遵循正規化理論的規約,盡可能少的冗餘字段,讓資料庫設計看起來精緻、優雅、讓人心醉。

合理的加入冗餘字段這個潤滑劑,減少join,讓資料庫執行效能更高更快。

選擇哪一種呢?如果你是乙個美學狂人,並且財大氣粗,非要使用第一種方案,也沒關係,這種方案的短板並非不可救藥的。比如,你可以增加伺服器,從資料庫集群入手,進行讀寫分離,讀的時候可以將壓力分散到不同的資料庫伺服器上,這樣也可以獲得很好的效能,只是多付出了硬體成本和維護成本。或者,你可以在資料庫前端架設memcached之類的快取服務,減少讀寫資料庫的次數,也可以達到同樣的效果。問題在於你確定你需要快取之類的東西。

當然,如果你跟我一樣,只有一台每月幾十元買來的vps,甚至可能是乙個虛擬主機,建議還是暫時壓制你的美學慾望,跟我一起選擇第二種方案吧,除非你願意你的整個資料庫都一直只有零零星星的幾條資料

資料庫設計 資料庫設計之欄位冗餘

學過資料庫設計的同學都知道,資料庫設計有三大正規化,但是在實際工作中,三大正規化很難被嚴格的執行。本文將給大家介紹一種常見的 違反正規化的資料庫設計方案 字段冗餘1 經典示例先來看乙個經典的例子,在一些 系統裡,要顯示已購買的訂單,一般會顯示訂單號 下單時間 訂單金額 商品名稱等,如下圖。正常我們如...

資料庫冗餘字段設計作用

在設計資料庫時,某一字段屬於乙個表,但它又同時出現在另乙個或多個表,且完全等同於它在其本來所屬表的意義表示,那麼這個字段就是乙個冗餘字段,外來鍵除外 以上是我自己給出的定義 冗餘欄位的存在到底是好還是壞呢?這是乙個不好說的問題。可能在有人看來,這是乙個很蹩腳的資料庫設計。因為在資料庫設計領域,有乙個...

資料庫冗餘字段設計作用

在設計資料庫時,某一字段屬於乙個表,但它又同時出現在另乙個或多個表,且完全等同於它在其本來所屬表的意義表示,那麼這個字段就是乙個冗餘字段。冗餘欄位的存在到底是好還是壞呢?這是乙個不好說的問題。可能在有人看來,這是乙個很蹩腳的資料庫設計。因為在資料庫設計領域,有乙個被大家必須遵守的資料庫設計正規化,這...