MySQL中數據中設計中的範式與反範式

設計關係數據庫時，聽從不一樣的規範要求，設計出合理的關係型數據庫，這些不一樣的規範要求被稱爲不一樣的範式，各類範式呈遞次規範，越高的範式數據庫冗餘越小。可是有些時候一昧的追求範式減小冗餘，反而會下降數據讀寫的效率，這個時候就要反範式，利用空間來換時間。

目前關係數據庫有六種範式：第一範式（1NF）、第二範式（2NF）、第三範式（3NF）、巴斯-科德範式（BCNF）、第四範式(4NF）和第五範式（5NF，又稱完美範式）。知足最低要求的範式是第一範式（1NF）。在第一範式的基礎上進一步知足更多規範要求的稱爲第二範式（2NF），其他範式以次類推。通常說來，數據庫只需知足第三範式(3NF）就好了。

三範式

第一範式（1NF）

即表的列的具備原子性,不可再分解，即列的信息，不能分解, 只要數據庫是關係型數據庫(mysql/oracle/db2/informix/sysbase/sql server)，就自動的知足1NF。

關係型數據庫: mysql/oracle/db2/informix/sysbase/sql server
非關係型數據庫: (特色: 面向對象或者集合)
NoSql數據庫: MongoDB/redis(特色是面向文檔)

第二範式（2NF）

第二範式（2NF）是在第一範式（1NF）的基礎上創建起來的，即知足第二範式（2NF）必須先知足第一範式（1NF）。第二範式（2NF）要求數據庫表中的每一個實例或行必須能夠被唯一地區分。爲實現區分一般須要咱們設計一個主鍵來實現(這裏的主鍵不包含業務邏輯)

第三範式（3NF）

知足第三範式（3NF）必須先知足第二範式（2NF）。簡而言之，第三範式（3NF）要求一個數據庫表中不包含已在其它表中已包含的非主鍵字段。就是說，表的信息，若是可以被推導出來，就不該該單獨的設計一個字段來存放(能儘可能外鍵join就用外鍵join)。不少時候，咱們爲了知足第三範式每每會把一張表分紅多張表

反三範式

沒有冗餘的數據庫未必是最好的數據庫，有時爲了提升運行效率，就必須下降範式標準，適當保留冗餘數據。具體作法是： 在概念數據模型設計時遵照第三範式，下降範式標準的工做放到物理數據模型設計時考慮。下降範式就是增長字段，減小了查詢時的關聯，提升查詢效率，由於在數據庫的操做中查詢的比例要遠遠大於DML的比例。可是反範式化必定要適度，而且在本來已知足三範式的基礎上再作調整的。

 

知乎上對範式和反範式的理解

摘自 https://www.zhihu.com/question/19900437
著做權歸做者全部。
商業轉載請聯繫做者得到受權，非商業轉載請註明出處。
做者：孫文亮
連接：https://www.zhihu.com/question/19900437/answer/14089402
來源：知乎

數據庫設計應該也是分爲三個境界的：
第一個境界，剛入門數據庫設計，範式的重要性還未深入理解。這時候出現的反範式設計，通常會出問題。
第二個境界，隨着遇到問題解決問題，漸漸瞭解到範式的真正好處，從而能快速設計出低冗餘、高效率的數據庫。
第三個境界，再通過N年的鍛鍊，是必定會發覺範式的侷限性的。此時再去打破範式，設計更合理的反範式部分。
範式就像武俠裏面的招數，初學者妄想不按招數來，只能死的很難堪。畢竟招數都是高手總結概括的精華。而隨着武功提升，招數熟練以後，必然是發現招數的侷限性，要麼忘掉招數，要麼自創招數。只要努力，加上多熬幾年，總能達到第二個境界，總會以爲範式是經典。此時能不過度依賴範式，快速突破範式侷限性的人，天然是高手。