如，以下是乙個大傢伙，使用者表user_info,它裡面有使用者的位址id，如cityid,可能還有使用者擴充套件表的資訊，使用者積分表的資訊等等，這些資訊至少需要三個表關聯才能得到我們所需要的資訊，而實際情況往往比這個還要複雜的多。
這時，一種資料冗餘的思想產生了，它相當於是用空間來換時間，即資料庫在磁碟上占用的空間多了，但查詢的效能提高了，這有時是我們可以接受的，規範固然重要，但有時也要具體問題具體去分析，對我們的user_info表進行改進後，可能是這樣的結構
userid
username
realname (真實姓名可能用的比較多，這時把它涉及到主表)
levelid
levelname(冗餘字段)
cityid
cityname(冗餘字段)
這時，如果我們要得到使用者所在的城市，從乙個表中就可以得到，省去了表的聯絡，從而提高了效能。
在使用冗餘資料做查詢時，我們很多時候為了減低資料庫的壓力，挺將這些資料進行快取，如使用redis進行快取服務，它可以為若干的站點進行服務，只要站點有合法的簽名即可。
資料庫正規化與反正規化
最近涉及到設計和建立數倉表，資料總體劃分為ods fact aggr dws rpt dim層，具體結構如下圖所示 遵從設計規則 以星型模型為設計模式,維度採用反正規化化,且維度資料要整個倉庫可共用,資料準確性要保證,事實表允許冗餘部分維度資料。針對其中幾個地方，解釋並mark一下。多維資料模型是最...
資料庫反正規化 認識三大正規化
有時，理論與實踐有一些差距，在做乙個具體的事情時，我們應該以實際為核心，而不是把理論死搬上來，要 從實際出發 呵呵。在資料庫的世界裡存在著三大正規化，也就是規範，真正的關係型資料庫應該盡可能的滿足這些規範，但有時，我們卻根據實際問題，需要違背這些規範，這個系列我將從實際專案 發來與大家一起說說 反正...
資料庫正規化設計和反正規化設計
1 庫表設計遵從三大正規化。a 資料庫設計的第一大正規化 資料庫表中的所有欄位都只具有單一屬性 單一屬性的列是由基本資料型別所構成的 設計出來的表都是簡單的二維表。乙個列存放的資訊只是乙個屬性的資訊，不能乙個字段存放多個屬性的組合資訊。即資料庫表中的所有字段值都是不可分解的原子值 b 資料庫設計的第...