資料庫設計

2022-07-13 13:33:12 字數 2713 閱讀 7085

資料庫優化是乙個綜合型的技術,並不是通過某一種方式讓資料庫效率提高很多,而是通過多方面的提高,從而使的資料庫提高很多

主要包括:

1.表的設計合理化(三正規化)

2.給表要新增合適的索引

3.分表技術(水平分割、垂直分割)

4.定時清除垃圾資料,定時進行碎片整理

5.對mysql的配置進行一些優化

6.讀寫分離

良好的資料庫:

1.節省儲存空間

2.保證資料完整性

糟糕的資料庫

1.資料冗餘,儲存空間的浪費

2.產生資料不完整

使用者發帖

回帖版塊

一對多:主鍵和非主鍵之間的關係,在多的一方建立乙個字段作為外來鍵指向一的一方的主鍵

多對多:建立乙個第三種表,中間表至少需要2個字段分別作為外來鍵指向多對多雙方的各自主鍵

一對一:

唯一外來鍵對應:假設一對一的雙方是一對多的關係,在多的一方建立外來鍵指向一的一方的主鍵,需要在外鍵

上新增乙個unique約束

主鍵對應:將一對一的雙方的主鍵建立對映

表設計出來以後,並不是合理的結構,我們需要對錶進行規範化(我們通過3正規化來對錶進行規範化)

第一正規化用來規範所有的字段,所有的字段都不可再分,兩列的屬性相近或相似或一樣,盡量合併屬性一樣的列,確保不產生冗餘資料。

注意:比如位址這個字段,如果不分類彙總,不排序,僅僅是起乙個字串的作用,這時我們不拆分

上圖所示的使用者資訊遵循第一正規化的要求,這樣對使用者使用城市進行分類的時候就非常方便,也提高了資料庫的效能。

第二正規化需要確保資料庫表中每一列都和主鍵相關,而不能只與主鍵的某一部分相關(主要針對聯合主鍵而言)。

也就是說在乙個資料庫表中,乙個表中只能儲存一種資料,不可以把多種資料儲存在同一張資料庫表中。

比如要設計乙個訂單資訊表,因為訂單中可能會有多種商品,所以要將訂單編號和商品編號作為資料庫表的聯合主鍵,如下圖。

這裡產生乙個問題:這個表中是以訂單編號和商品編號作為聯合主鍵,這樣在該表中商品名稱、單位、商品**等資訊不與該錶的主鍵相關,

而僅僅是與商品的編號相關,所以在這裡違反了第二正規化的設計原則。

而如果把這個訂單資訊表進行拆分,把商品資訊分離到另乙個表中,把訂單專案表也分離到另乙個表中,就非常完美了,如下圖。

這裡這樣設計,在很大程度上減小了資料庫的冗餘,如果要獲取訂單的商品資訊,使用商品編號到商品資訊表中查詢即可。

在非主鍵欄位中,如果乙個字段可以推導出另外乙個字段

比如在設計乙個訂單資料表的時候,可以將客戶編號作為乙個外來鍵和訂單表建立相應的關係,而不可以在訂單表中新增關於客戶其他資訊(比如姓名、所屬公司)的字段,

如下面這兩個表所示的設計就是乙個滿足第三正規化的資料庫表。

這樣在查詢訂單資訊的時候,就可以使用客戶編號來引用客戶資訊表中的記錄,也不必再訂單資訊表中多次輸入客戶資訊的內容,減小了資料冗餘。

沒有冗餘的資料庫設計可以做到。但是,沒有冗餘的資料庫未必是最好的資料庫,有時為了提高執行效率,就必須降低正規化標準,

適當保留冗餘資料。具體做法是:在概念資料模型設計時遵守第三正規化,降低正規化標準的工作放到物理資料模型設計時考慮。降低正規化就是增加字段,允許冗餘,

達到以空間換時間的目的

1.資料庫效能和規範化資料庫更重要

通過在給定的表中新增額外的字段,以減少需要從中搜尋資訊所需要的時間

通過在給定的表中插入計算列(查詢總分),以方便查詢

2進行規範化的同時,還需要綜合考慮資料庫效能

1.正規化化

優點

缺點

2.反正規化化

優點

資料庫設計 設計資料庫之前

1.考察現有環境 在設計乙個新資料庫時,你不但應該仔細研究業務需求而且還要考察現有的系統。大多數資料庫 專案都不是從頭開始建立的 通常,機構內總會存在用來滿足特定需求的現有系統 可能沒有實 現自動計算 顯然,現有系統並不完美,否則你就不必再建立新系統了。但是對舊系統的研究 可以讓你發現一些可能會忽略...

資料庫設計 設計資料庫之前

1.考察現有環境 在設計乙個新資料庫時,你不但應該仔細研究業務需求而且還要考察現有的系統。大多數資料庫 專案都不是從頭開始建立的 通常,機構內總會存在用來滿足特定需求的現有系統 可能沒有實 現自動計算 顯然,現有系統並不完美,否則你就不必再建立新系統了。但是對舊系統的研究 可以讓你發現一些可能會忽略...

資料庫設計 設計資料庫之前

1.考察現有環境 在設計乙個新資料庫時,你不但應該仔細研究業務需求而且還要考察現有的系統。大多數資料庫 專案都不是從頭開始建立的 通常,機構內總會存在用來滿足特定需求的現有系統 可能沒有實 現自動計算 顯然,現有系統並不完美,否則你就不必再建立新系統了。但是對舊系統的研究 可以讓你發現一些可能會忽略...