Mysql中范式和反范式的優(yōu)缺點(diǎn)

今天就跟大家聊聊有關(guān)Mysql中范式和反范式的優(yōu)缺點(diǎn)，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

一、三大范式

第一范式

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

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

第二范式

2NF是對記錄的惟一性，要求記錄有惟一標(biāo)識，即實(shí)體的惟一性，即不存在部分依賴；

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

第三范式

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

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

范式的利弊：

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

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

二、反范式

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

反范式的利弊：

優(yōu)點(diǎn)：查詢時(shí)可以減少表的關(guān)聯(lián)；可以更好的進(jìn)行索引優(yōu)化；

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

看完上述內(nèi)容，你們對Mysql中范式和反范式的優(yōu)缺點(diǎn)有進(jìn)一步的了解嗎？如果還想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀。