Mysql范式與反范式的詳細說明

本篇內(nèi)容主要講解“Mysql范式與反范式的詳細說明”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Mysql范式與反范式的詳細說明”吧!

第一范式（1NF）

第一范式，強調(diào)屬性的原子性約束，要求屬性具有原子性，不可再分解。

舉個例子：活動表（活動編碼，活動名稱，活動地址），假設這個場景中，活動地址可以細分為國家、省份、城市、市區(qū)、位置，那么就沒有達到第一范式。

第二范式（2NF）

第二范式，強調(diào)記錄的唯一性約束，表必須有一個主鍵，并且沒有包含在主鍵中的列必須完全依賴于主鍵，而不能只依賴于主鍵的一部分。

舉個例子：版本表（版本編碼，版本名稱，產(chǎn)品編碼，產(chǎn)品名稱），其中主鍵是（版本編碼，產(chǎn)品編碼），這個場景中，數(shù)據(jù)庫設計并不符合第二范式，因為產(chǎn)品名稱只依賴于產(chǎn)品編碼。存在部分依賴。所以，為了使其滿足第二范式，可以改造成兩個表：版本表（版本編碼，產(chǎn)品編碼）和產(chǎn)品表（產(chǎn)品編碼，產(chǎn)品名稱）。

第三范式（3NF）

第三范式，強調(diào)屬性冗余性的約束，即非主鍵列必須直接依賴于主鍵。

舉個例子，訂單表（訂單編碼，顧客編碼，顧客名稱），其中主鍵是（訂單編碼），這個場景中，顧客編碼、顧客名稱都完全依賴于主鍵，因此符合第二范式，但是顧客名稱依賴于顧客編碼，從而間接依賴于主鍵，所以不能滿足第三范式。為了使其滿足第三范式，可以拆分兩個表：訂單表（訂單編碼，顧客編碼）和顧客表（顧客編碼，顧客名稱），拆分后的數(shù)據(jù)庫設計，就可以完全滿足第三范式的要求了。

值得注意的是，第二范式的側重點是非主鍵列是否完全依賴于主鍵，還是依賴于主鍵的一部分。第三范式的側重點是非主鍵列是直接依賴于主鍵，還是直接依賴于非主鍵列。

反范式

范式可以避免數(shù)據(jù)冗余，減少數(shù)據(jù)庫的空間，減輕維護數(shù)據(jù)完整性的麻煩。 然而，通過數(shù)據(jù)庫范式化設計，將導致數(shù)據(jù)庫業(yè)務涉及的表變多，并且可能需要將涉及的業(yè)務表進行多表連接查詢，這樣將導致性能變差，且不利于分庫分表。因此，出于性能優(yōu)先的考量，可能在數(shù)據(jù)庫的結構中需要使用反范式的設計，即空間換取時間，采取數(shù)據(jù)冗余的方式避免表之間的關聯(lián)查詢。至于數(shù)據(jù)一致性問題，因為難以滿足數(shù)據(jù)強一致性，一般情況下，使存儲數(shù)據(jù)盡可能達到用戶一致，保證系統(tǒng)經(jīng)過一段較短的時間的自我恢復和修正，數(shù)據(jù)最終達到一致。

需要謹慎使用反模式設計數(shù)據(jù)庫。一般情況下，盡可能使用范式化的數(shù)據(jù)庫設計，因為范式化的數(shù)據(jù)庫設計能讓產(chǎn)品更加靈活，并且能在數(shù)據(jù)庫層保持數(shù)據(jù)完整性。

有的時候，提升性能最好的方法是在同一表中保存冗余數(shù)據(jù)，如果能容許少量的臟數(shù)據(jù)，創(chuàng)建一張完全獨立的匯總表或緩存表是非常好的方法。舉個例子，設計一張“下載次數(shù)表”來緩存下載次數(shù)信息，可使在海量數(shù)據(jù)的情況下，提高查詢總數(shù)信息的速度。

另外一個比較典型的場景，出于擴展性考慮，可能會使用 BLOB 和 TEXT 類型的列存儲 JSON 結構的數(shù)據(jù)，這樣的好處在于可以在任何時候，將新的屬性添加到這個字段中，而不需要更改表結構。但是，這個設計的缺點也比較明顯，就是需要獲取整個字段內(nèi)容進行解碼來獲取指定的屬性，并且無法進行索引、排序、聚合等操作。因此，如果需要考慮更加復雜的使用場景，更加建議使用 MongoDB 這樣的文檔型數(shù)據(jù)庫。

真實場景很難做到范式化，一般會選擇性能，保證最終一致性。

到此，相信大家對“Mysql范式與反范式的詳細說明”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關內(nèi)容可以進入相關頻道進行查詢，關注我們，繼續(xù)學習！