數據庫結構的優化

數據庫設計的步驟：

1. 需求分析：全面瞭解產品設計的存儲需求
2. 邏輯設計：設計數據的邏輯存儲結構
3. 物理設計：根據所使用的數據庫特色進行表結構的設計
4. 維護優化：根據實際的狀況對索引、存儲引擎的優化 ###數據庫的範式：
5. 第一範式：數據庫中的全部字段都只是具備單一的屬性
6. 第二範式：在第一範式的條件下，要求一個表中只具備一個業務主鍵，每一個表只作一件事情
7. 第三範式：在第二範式基礎上，消除表中的傳遞依賴關係

1、需求分析及邏輯設計

用戶模塊

• 用戶必須註冊並等咯系統才能進行網上的交易
• 同一時間一個用戶只能在一個地方登錄
• 用戶的信息:{用戶名，密碼，手機號，姓名，註冊日期，在線狀態，出生日期}

商品模塊

• 商品信息:{商品名稱，出版社名稱，圖書的價格，圖書描述，做者}
• 分類信息：{分類名稱，分類描述}
• 商品分類信息（對應關係表）：{商品名稱，分類名稱}

供應商模塊

• 供應商的信息：{出版社名稱，地址，電話，聯繫人，銀行帳號}

在線銷售模塊

• 在線銷售所須要的數據：{訂單編號，下單用戶名，下單日期，訂單金額，訂單商品分類，訂單商品名，訂單商品的單價，訂單商品數量，支付金額，物流單號}
• 訂單表：{訂單編號，下單用戶名，下單日期，支付金額，物流單號}
• 訂單商品的關聯表：{訂單編號，訂單商品分類，訂單商品名，商品數量}

考慮性能的問題及商品價格發生變化：

• 商品信息表的反範式化設計：

  商品信息:{商品名稱，分類名稱，出版社名稱，圖書的價格，圖書描述，做者}

  分類信息：{分類名稱，分類描述}

• 在線銷售表的反範式化設計：

  訂單表：{訂單編號，下單用戶名，手機號，下單日期，支付金額，物流單號，訂單金額}

  訂單商品的關聯表：{訂單編號，訂單商品分類，訂單商品名，商品數量，商品單價}

• 反範式化後的查詢每一個用戶的訂單的總金額的SQL語句：

  select 下單用戶名,sum(訂單金額) from 訂單表 group by 下單用戶名；

• 反範式化後的查詢下單用戶和訂單詳情的SQL語句：

  select a.訂單編號，a.用戶名，a.手機號，b.商品名稱，b.商品的單價，b.商品數量 from 訂單表 a join 訂單商品的關聯表 b on a.訂單編號=b.訂單編號； ###範式化的優缺點

範式化的優勢：

• 能夠儘可能的減小冗餘數據
• 範式的更新操做比反範式化要快
• 範式化的表一般比反範式化的表更小

範式化的缺點：

• 對查詢須要對多個表進行關聯
• 更難進行索引優化 ###反範式化的優缺點

反範式化的優勢：

• 能夠很好的減小表的關聯
• 能夠對查詢進行索引優化

反範式化的缺點：

• 存在數據冗餘及數據維護異常
• 對數據的修改須要更多的成本

2、數據庫的物理設計階段

• 定義數據庫、表及字段的命名規範（可讀性原則、表意性原則、長名原則）
• 選擇合適的存儲引擎

• 爲表中的字段選擇合適的數據類型（當一個列能夠選擇多種數據類型時，應該優先考慮數字類型，其次是日期類型或者二進制類型，最後是字符類型。對於相同級別的數據類型，應該優先選擇佔用空間小的數據類型）

  整數類型：

  tinyint(1個字節)、smallint(2個字節)、
    mediumint(3個字節)、int(4個字節)、bigint(8個字節)
  複製代碼

  實數類型：

  float(4個字節，不爲精確類型)、double(8個字節，不爲精確類型)、
    decimal(每4個字節存9個數字，小數點佔一個字節，爲精確類型)
  複製代碼

  varchar和char類型：

  varchar類型存儲特色：
    	用於存儲變長字符串，只佔用必要的存儲空間；
    	列的最大長度小於255時則只佔用一個額外字節用於記錄字符串長度；
    	列的最大長度大於255則，要佔用兩個額外字節用於記錄字符串長度
  
    如何對varchar列選擇合適的寬度：
  
    	使用最小的符合需求的長度；
    	varchar(5)和varchar(200)存儲MySQL字符串性能不一樣
  
    varchar的適用場景：
  
    	字符串列的最大長度比平均長度大不少；
    	字符串列不多被更新的字符串的列；
    	使用了多字符集存儲字符串
  
    char類型存儲特色：
  
    	char類型是定長的；
    	字符串存儲在char類型的列中會刪除末尾的空格；
    	char類型存儲的最大的寬度是255
  
    char類型的適用的場景：
  
    	適合存儲所長度近似的值（eg:md5的值、手機號、身份證號）
    	適合存儲長度短小的字符串
    	適合存儲存儲常常更新的字符串
  複製代碼

  日期類型：

  datatime類型以YYYY-MM-DD HH:MM:SS[.fraction]格式存儲數據
    datatime類型與時區無關，佔用8個字節存儲空間
    存儲的時間範圍：1000-01-01 00：00:00到9999-12-31 23:59:59
  
    timestamp類型存儲從1970年1月1日到當前的秒數，以YYYY-MM-DD HH:MM:SS[.fraction]顯示，佔用4個字節存儲空間
    timestamp類型顯示依賴於所指定的時區
    timestamp類型在行數據修改時能夠自動修改timestamp列的值
    timestamp存儲的時間範圍1970-01-01到2038-01-19
  
    date類型和time類型（mysql5.7以後加入）：
    	date類型佔用的字節數比使用字符串、datatime、int存儲要少，使用date類型只須要3個字節；
    	date類型使用Date類型還能夠利用日期時間函數進行日期之間的計算；
    	date類型存儲的日期範圍1000-01-01到9999-12-31之間的日期
  
    	time類型用於存儲時間數據：HH:MM:SS
    存儲日期時間類型的注意事項：
    	不要使用字符串類型來存儲日期時間數據；
    		日期時間類型一般比字符串類型所佔用的存儲空間小；
    		日期時間類型在進行查找過濾時能夠利用日期來進行對比；
    		日期時間類型有豐富的處理函數，能夠方便的對時間類型的進行日期計算
    	使用Int存儲日期時間不如使用Timestamp類型
  複製代碼

  InnoDB如何選擇主鍵： 主鍵應該儘量的小； 主鍵應該是順序增加的（以減小隨機IO），增長數據的插入效率； InnoDB的主鍵和業務主鍵能夠不一樣

• 創建數據庫結構

• 維護優化數據庫