轉載自http://chenhaoxiang.cn/2018/02/04/2158/

數據庫設計無非遵循的就是減少冗余量，第二點就是遵循三范式

第一范式(1NF)

確保每一列的原子性

也就是如果每一列都滿足是不可再分的最小數據單元，則滿足第一范式

比如
id name sex address
1 chx 0 湖南長沙

在這里，其實地址這個字段是可以再拆分的，拆分成省份，市區。
但是，在有的場景下，也可以不分。
需要根據具體的需求來看是否需要拆分
這里的保證原子性，具體看業務需求
如果僅僅只是起字符串的作用，在這里的地址，就可以不分。
加入是電商項目，需要分地區等等收貨地址，在這里就可以再分細一些

第二范式(2NF)

主要是保證唯一
如果一個關系滿足一范式，并且除了主鍵以外的其他列，都依賴于該主鍵，則滿足第二范式。

通俗來講，就是每一個表有且僅有一個主關鍵字，其他數據與主關鍵字一一對應。注意，這里的主關鍵字肯定是主鍵，但是主鍵不一定是主關鍵字。
參考百度百科:第二范式

一般訂單表中，我們都不會用id來作為訂單號
如果需要訂單號，我們就要建一個orderid列
這樣也是為了安全性著想。項目內部是用id進行通訊的，而外部，我們就使用orderid來進行通訊
另外就是，在分布式系統中，解決并發生成訂單號
比如，搶票分布式系統中，如何保證訂單號不會重復生成(也就是怎么保證訂單的冪等性)
提前將訂單號生成好，存放在redis中，在需要的時候，直接去redis中去取。這樣就可以保證訂單的冪等性

第三范式(3NF)

指表中的所有數據元素不但要能惟一地被主關鍵字所標識,而且它們之間還必須相互獨立,不存在其他的函數關系。

其實理解起來就是不要有冗余數據
比如:
學號 姓名 所在系 系名稱 系地址
在這里學號決定各個屬性，由于是單個關鍵字，沒有部分依賴的問題，肯定是2NF。但是卻有大量的數據冗余，有關學生的所在系 系名稱 系地址。

所以可以將一個表拆分為兩個表
學號 姓名 所在系 和 所在系 系名稱 系地址

注意這兩個表之間的聯系在所在系這個外關鍵字

不過有點時候，不一定要完全遵循第三范式
有的時候，為了業務需求，完全可以接收一些數據的冗余
比如一些視頻網站。
課程表：
課程id 課程name 瀏覽量
1 java 2000

課程詳情表：
詳情id 詳情name 詳情瀏覽量 課程id
1 java基礎1 1000 1
1 java基礎2 1000 1
前面課程表如果沒有瀏覽量，每次都需要查詢詳情表的sum，這樣效率非常低，這個時候就可以在課程表增加一個瀏覽量字段

所以說，沒有死的設計，只有具體的需求

雖然市面上還有4NF，5NF，但是主流還是3NF，其他的，有興趣的朋友可以自己搜索了解一下

本文章由[諳憶]編寫， 所有權利保留。
歡迎轉載，分享是進步的源泉。

總結

以上是生活随笔為你收集整理的【MySQL性能优化】数据库设计三大范式(二)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。