數(shù)據(jù)庫設(shè)計的步驟：
需求分析：全面了解產(chǎn)品設(shè)計的存儲需求
邏輯設(shè)計：設(shè)計數(shù)據(jù)的邏輯存儲結(jié)構(gòu)
物理設(shè)計：根據(jù)所使用的數(shù)據(jù)庫特點(diǎn)進(jìn)行表結(jié)構(gòu)的設(shè)計
維護(hù)優(yōu)化：根據(jù)實際的情況對索引、存儲引擎的優(yōu)化
###數(shù)據(jù)庫的范式：
第一范式：數(shù)據(jù)庫中的所有字段都只是具有單一的屬性
第二范式：在第一范式的條件下岩遗，要求一個表中只具有一個業(yè)務(wù)主鍵，每個表只做一件事情
第三范式：在第二范式基礎(chǔ)上仆抵，消除表中的傳遞依賴關(guān)系
一架曹、需求分析及邏輯設(shè)計
用戶模塊
用戶必須注冊并等咯系統(tǒng)才能進(jìn)行網(wǎng)上的交易
同一時間一個用戶只能在一個地方登陸
用戶的信息:{用戶名莫杈，密碼，手機(jī)號挎挖，姓名这敬，注冊日期，在線狀態(tài)蕉朵，出生日期}商品模塊
商品信息:{商品名稱崔涂，出版社名稱，圖書的價格始衅，圖書描述冷蚂，作者}
分類信息：{分類名稱，分類描述}
商品分類信息（對應(yīng)關(guān)系表）：{商品名稱汛闸，分類名稱}供應(yīng)商模塊
供應(yīng)商的信息：{出版社名稱蝙茶，地址，電話诸老，聯(lián)系人隆夯，銀行賬號}在線銷售模塊
在線銷售所需要的數(shù)據(jù)：{訂單編號，下單用戶名，下單日期蹄衷，訂單金額忧额，訂單商品分類，訂單商品名愧口，訂單商品的單價睦番，訂單商品數(shù)量，支付金額调卑，物流單號}
訂單表：{訂單編號抡砂，下單用戶名，下單日期恬涧，支付金額，物流單號}
訂單商品的關(guān)聯(lián)表：{訂單編號碴巾，訂單商品分類溯捆，訂單商品名，商品數(shù)量}考慮性能的問題及商品價格發(fā)生變化：
商品信息表的反范式化設(shè)計： 商品信息:{商品名稱厦瓢，分類名稱提揍，出版社名稱，圖書描述煮仇，作者}分類信息：{分類名稱劳跃，分類描述}
在線銷售表的反范式化設(shè)計： 訂單表：{訂單編號，下單用戶名浙垫，手機(jī)號刨仑，下單日期，支付金額夹姥，物流單號杉武，訂單金額}訂單商品的關(guān)聯(lián)表：{訂單編號，訂單商品分類辙售，訂單商品名轻抱，商品數(shù)量，商品單價}
反范式化后的查詢每個用戶的訂單的總金額的SQL語句： select 下單用戶名,sum(訂單金額) from 訂單表 group by 下單用戶名旦部；
反范式化后的查詢下單用戶和訂單詳情的SQL語句：
select a.訂單編號祈搜，a.用戶名，a.手機(jī)號士八，b.商品名稱容燕，b.商品的單價，b.商品數(shù)量 from 訂單表 a join 訂單商品的關(guān)聯(lián)表 b on a.訂單編號=b.訂單編號曹铃；
###范式化的優(yōu)缺點(diǎn)
范式化的優(yōu)點(diǎn)：
可以盡量的減少冗余數(shù)據(jù)
范式的更新操作比反范式化要快
范式化的表通常比反范式化的表更小范式化的缺點(diǎn)：
對查詢需要對多個表進(jìn)行關(guān)聯(lián)
更難進(jìn)行索引優(yōu)化
###反范式化的優(yōu)缺點(diǎn)反范式化的優(yōu)點(diǎn)：
可以很好的減少表的關(guān)聯(lián)
可以對查詢進(jìn)行索引優(yōu)化反范式化的缺點(diǎn)：
存在數(shù)據(jù)冗余及數(shù)據(jù)維護(hù)異常
對數(shù)據(jù)的修改需要更多的成本二缰趋、數(shù)據(jù)庫的物理設(shè)計階段
定義數(shù)據(jù)庫、表及字段的命名規(guī)范（可讀性原則、表意性原則秘血、長名原則）
選擇合適的存儲引擎
為表中的字段選擇合適的數(shù)據(jù)類型（當(dāng)一個列可以選擇多種數(shù)據(jù)類型時味抖，應(yīng)該優(yōu)先考慮數(shù)字類型，其次是日期類型或者二進(jìn)制類型灰粮，最后是字符類型仔涩。對于相同級別的數(shù)據(jù)類型，應(yīng)該優(yōu)先選擇占用空間小的數(shù)據(jù)類型）
整數(shù)類型：
tinyint(1個字節(jié))粘舟、smallint(2個字節(jié))熔脂、
mediumint(3個字節(jié))、int(4個字節(jié))柑肴、bigint(8個字節(jié))
實數(shù)類型：java學(xué)習(xí)交流群：478052716
float(4個字節(jié)霞揉，不為精確類型)、double(8個字節(jié)晰骑，不為精確類型)适秩、
decimal(每4個字節(jié)存9個數(shù)字，小數(shù)點(diǎn)占一個字節(jié)硕舆，為精確類型)
varchar和char類型：java學(xué)習(xí)交流群：478052716
varchar類型存儲特點(diǎn)：
用于存儲變長字符串秽荞，只占用必要的存儲空間；
列的最大長度小于255時則只占用一個額外字節(jié)用于記錄字符串長度抚官；
列的最大長度大于255則扬跋，要占用兩個額外字節(jié)用于記錄字符串長度
如何對varchar列選擇合適的寬度：
使用最小的符合需求的長度；
varchar(5)和varchar(200)存儲MySQL字符串性能不同
varchar的適用場景：
字符串列的最大長度比平均長度大很多凌节；
字符串列很少被更新的字符串的列钦听；
使用了多字符集存儲字符串
char類型存儲特點(diǎn)：
char類型是定長的；
字符串存儲在char類型的列中會刪除末尾的空格刊咳；
char類型存儲的最大的寬度是255
char類型的適用的場景：
適合存儲所長度近似的值（eg:md5的值彪见、手機(jī)號、身份證號）
適合存儲長度短小的字符串
適合存儲存儲經(jīng)常更新的字符串
日期類型：java學(xué)習(xí)交流群：478052716
datatime類型以YYYY-MM-DD HH:MM:SS[.fraction]格式存儲數(shù)據(jù)
datatime類型與時區(qū)無關(guān)娱挨，占用8個字節(jié)存儲空間
存儲的時間范圍：1000-01-01 00：00:00到9999-12-31 23:59:59
timestamp類型存儲從1970年1月1日到當(dāng)前的秒數(shù)余指，以YYYY-MM-DD HH:MM:SS[.fraction]顯示，占用4個字節(jié)存儲空間
timestamp類型顯示依賴于所指定的時區(qū)
timestamp類型在行數(shù)據(jù)修改時可以自動修改timestamp列的值
timestamp存儲的時間范圍1970-01-01到2038-01-19
date類型和time類型（mysql5.7之后加入）：
date類型占用的字節(jié)數(shù)比使用字符串跷坝、datatime酵镜、int存儲要少，使用date類型只需要3個字節(jié)柴钻；
date類型使用Date類型還可以利用日期時間函數(shù)進(jìn)行日期之間的計算淮韭；
date類型存儲的日期范圍1000-01-01到9999-12-31之間的日期
time類型用于存儲時間數(shù)據(jù)：HH:MM:SS
存儲日期時間類型的注意事項：
不要使用字符串類型來存儲日期時間數(shù)據(jù)；
日期時間類型通常比字符串類型所占用的存儲空間刑臁靠粪；
日期時間類型在進(jìn)行查找過濾時可以利用日期來進(jìn)行對比蜡吧；
日期時間類型有豐富的處理函數(shù)，可以方便的對時間類型的進(jìn)行日期計算
使用Int存儲日期時間不如使用Timestamp類型
InnoDB如何選擇主鍵：
主鍵應(yīng)該盡可能的姓技昔善；
主鍵應(yīng)該是順序增長的（以減少隨機(jī)IO），增加數(shù)據(jù)的插入效率畔乙；
InnoDB的主鍵和業(yè)務(wù)主鍵可以不同
建立數(shù)據(jù)庫結(jié)構(gòu)
維護(hù)優(yōu)化數(shù)據(jù)庫
