這篇文章主要講解了“MySQL范式與反范式的利弊是什么”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Mysql范式與反范式的利弊是什么”吧！

修文網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)！從網(wǎng)頁設計、網(wǎng)站建設、微信開發(fā)、APP開發(fā)、響應式網(wǎng)站建設等網(wǎng)站項目制作，到程序開發(fā)，運營維護。創(chuàng)新互聯(lián)于2013年創(chuàng)立到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進行。專注于網(wǎng)站建設就選創(chuàng)新互聯(lián)。

一、三大范式

第一范式

1NF是對屬性的原子性，要求屬性具有原子性，不可再分解；

第一范式是最基本的范式。如果數(shù)據(jù)庫表中的所有字段值都是不可分解的原子值，就說明該數(shù)據(jù)庫表滿足了第一范式。數(shù)據(jù)庫表的每一列都是不可分割的原子數(shù)據(jù)項，而不能是集合，數(shù)組，記錄等非原子數(shù)據(jù)項。簡而言之，第一范式就是無重復的域。

第二范式

2NF是對記錄的惟一性，要求記錄有惟一標識，即實體的惟一性，即不存在部分依賴；

滿足第二范式必須先滿足第一范式。第二范式需要確保數(shù)據(jù)庫表中的每一列都和主鍵相關，而不能只與主鍵的某一部分相關(主要針對聯(lián)合主鍵而言)。也就是說在一個數(shù)據(jù)庫表中，一個表中只能保存一種數(shù)據(jù)，不可以把多種數(shù)據(jù)保存在同一張數(shù)據(jù)庫表中。

第三范式

3NF是對字段的冗余性，要求任何字段不能由其他字段派生出來，它要求字段沒有冗余，即不存在傳遞依賴；

首先是2NF，另外非主鍵列必須直接依賴于主鍵，不能存在傳遞依賴。即不能存在：非主鍵列A依賴于非主鍵列B，非主鍵列B依賴于主鍵的情況。簡而言之，第三范式（3NF）要求一個關系中不包含已在其它關系已包含的非主關鍵字信息。例如，存在一個部門信息表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等信息。那么在員工信息表中列出部門編號后就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。

范式的利弊：

優(yōu)點：范式可以避免數(shù)據(jù)冗余，減少數(shù)據(jù)庫的空間，減輕維護數(shù)據(jù)完整性的麻煩。

缺點：按照范式的規(guī)范設計出來的表，等級越高的范式設計出來的表越多。如第一范式可能設計出來的表可能只有一張表而已，再按照第二范式去設計這張表時就可能出來兩張或更多張表，如果再按第三范式或更高的范式去設計這張表會出現(xiàn)更多比第二范式多的表。表的數(shù)量越多，當我們去查詢一些數(shù)據(jù)，必然要去多表中去查詢數(shù)據(jù)，這樣查詢的時間要比在一張表中查詢中所用的時間要高很多。也就是說我們所用的范式越高，對數(shù)據(jù)操作的性能越低。所以我們在利用范式設計表的時候，要根據(jù)具體的需求再去權衡是否使用更高范式去設計表。

二、反范式

故名思義，跟范式所要求的正好相反，在反范式的設計模式，我們可以允許適當?shù)臄?shù)據(jù)的冗余，用這個冗余去取操作數(shù)據(jù)時間的縮短。也就是用空間來換取時間,把數(shù)據(jù)冗余在多個表中，當查詢時可以減少或者是避免表之間的關聯(lián)。

反范式的利弊：

優(yōu)點：查詢時可以減少表的關聯(lián)；可以更好的進行索引優(yōu)化；

缺點：存在數(shù)據(jù)冗余以及數(shù)據(jù)維護異常；對數(shù)據(jù)的修改需要更多的成本

感謝各位的閱讀，以上就是“Mysql范式與反范式的利弊是什么”的內容了，經(jīng)過本文的學習后，相信大家對Mysql范式與反范式的利弊是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關知識點的文章，歡迎關注！