数据库设计总结
1.什么是數(shù)據(jù)庫設計
數(shù)據(jù)庫設計就是根據(jù)業(yè)務的具體需求，結合我們所選用的DBMS，為這個業(yè)務系統(tǒng)造出最優(yōu)的數(shù)據(jù)存儲模型、
并建立好數(shù)據(jù)庫中的表結構及表與表之間的關聯(lián)關系的過程。讓它有效的對應用系統(tǒng)中的數(shù)據(jù)進行存儲，并可以
高效的對已經(jīng)存儲的數(shù)據(jù)進行訪問。
2.為什么要進行數(shù)據(jù)庫設計
? 1.減少數(shù)據(jù)冗余2.避免數(shù)據(jù)維護異常3.節(jié)約存儲空間3.高效訪問
3.分析需求
以電商為例子? 核心模塊? 用戶模塊，商品模塊，訂單模塊，購物車模塊，供應商模塊。
用戶模塊
包括的屬性：用戶名，密碼，電話，郵箱，身份證號，地址，姓名，昵稱。。。。。
唯一標識屬性：用戶名，身份證，電話
存儲特點：隨時間增加逐漸增加，但是需要永久儲存
商品模塊
包括屬性：商品編碼，商品名稱，描述，類，重量，有效期，價格。。。。。。
唯一：編碼
存儲特點：對下線的商品可以歸檔存儲，不能刪除，因為購物車或者訂單里面還有該商品
訂單
屬性：訂單號，用戶名，電話，收貨地址，商品。。。。。
唯一標識：訂單號
存儲特點：永久存儲（分表，分庫）
購物車模塊
屬性：用戶名，商品編號，價格，描述，分類，加入時間，數(shù)量。。。
唯一標識：用戶名，編號，加入時間
存儲特點：不用永久存儲，設置歸檔，清理規(guī)則
4.邏輯設計（ER圖）
關系：一個關系通常就是一張表
元組：表中的一行即為一個元組
屬性：表中的一列即為一個屬性；每一個屬性都有一個名稱，成為屬性名
候選碼：表中的某個屬性組，它可以唯一確定一個元組
主碼：一個關系有多個候選碼，炫動其中一個為主碼
域：屬性的取值范圍
分量：元組中的一個屬性值
5.*******設計范式概要
操作異常：
1.插入異常：如果實體隨著另一個實體存在而存在，即缺少某一個實體時無法表示這個實體，那么這個表就存在插入異常
2.更新異常：如果更改表所對應的某個實體實例的單獨屬性時，需要將多行跟新，那么就說這個表存在更新異常
3.刪除異常：如果刪除表的某一行來反映某實體實例失效時導致另一個不同的實體實例信息丟失
數(shù)據(jù)冗余：是指數(shù)據(jù)在多個地方存在，或者說表中的某個列可以有其他列計算得到，這樣表中存在在數(shù)據(jù)冗余
主要有第一范式 第二范式，第三范式，BC范式
第一范式：數(shù)據(jù)表中的字段都是單一屬性，不可再分的，這個單一屬性是由基本的數(shù)據(jù)類型所構成的。簡單地說：第一范式要求數(shù)據(jù)庫中表都是二維表
?
第二范式：數(shù)據(jù)庫的表中不存在非關鍵字段對任一候選關鍵字段的不分函數(shù)依賴，簡單地說：所有單關鍵字段的表都符合第二范式。
? ? ? ??
第三范式：第三范式存在第二范式基礎之上定義的，如果數(shù)據(jù)表中不存在非關鍵字段，對任一候選關鍵字段的傳遞函數(shù)依賴則符合第三范式
BC范式：在第三范式的基礎上，數(shù)據(jù)庫表中如果不存在任何字段對任一候選關鍵字段的傳遞函數(shù)依賴則符合BC范式，也就是說如果是復合關鍵字，則復合關鍵字之間也不能存在函數(shù)依賴關系。
?
?
6.物理設計
1.選擇合適的數(shù)據(jù)庫管理系統(tǒng)
常見的DBMS：Oracle和SQLServer（只支持windows，適用于.net開發(fā)，erp系統(tǒng)）屬于商業(yè)數(shù)據(jù)庫（常用于企業(yè)級項目），MySQL和PgSQL是開源數(shù)據(jù)庫（常用于互聯(lián)網(wǎng)項目）
Oracel適用于大的事務操作。
MySQL的存儲引擎：
?
2.定義數(shù)據(jù)庫，表及字段的名稱規(guī)范
英文，顧名思義
3.根據(jù)所選的DBMS系統(tǒng)選擇合適的字段類型
?
1.數(shù)據(jù)查詢比較：同樣的數(shù)據(jù)，字符串處理比數(shù)字慢**
2.數(shù)據(jù)庫中，數(shù)據(jù)處理以頁為單位，列長度越小，利于性能提升****
例如char和varchar如何選擇
1.如果列中要存儲的數(shù)據(jù)長度差不多是一致的。則選擇char
2.如果列中最大數(shù)據(jù)長度小于50byte，則用char（如果列很少用，基于節(jié)省空間和減少I/O的考慮，還是可以考慮varchar）
decimal和float的選擇
1.decimal用于存儲精確數(shù)據(jù)，而float只能用于存儲非精確數(shù)據(jù)
2.由于float的存儲空間開銷一般比decimal小（精確到7位數(shù)只需要4byte，精確到15位也只有8byte）優(yōu)先選擇float
時間類型
1.int存儲時間字段的優(yōu)缺點
優(yōu)點：字段長度比datetime小
缺點：使用不方便，要進行轉換
限制：只能存儲到2.38-1-19? 2147483648=2^32
2.需要存儲的時間粒度
年 月 日 小時 分 秒 周
如何選擇主鍵
1.區(qū)分業(yè)務主鍵和數(shù)據(jù)庫主鍵
業(yè)務逐漸標識業(yè)務數(shù)據(jù)，進行表與表的關聯(lián)；數(shù)據(jù)庫主鍵則是為了優(yōu)化數(shù)據(jù)存儲（innodeb會生成6個字節(jié)的隱含主鍵）
2.跟數(shù)據(jù)庫的類型，考慮主鍵是否順序增長
有些數(shù)據(jù)庫是按主鍵的順序邏輯存儲的
3.主鍵的字段類型所占空間盡可能的小
對于使用聚集索引范式存儲的表，每個索引后都會附加主鍵信息
?
避免使用外鍵約束
1.降低數(shù)據(jù)導入的效率
2.增加維護成本
3.雖然不建議使用外鍵約束，但是相關聯(lián)的列上一定要建立索引
避免使用觸發(fā)器
1.降低數(shù)據(jù)導入的效率
2.可能會出現(xiàn)意想不到的數(shù)據(jù)異常
3.使業(yè)務邏輯變得復雜
預留字段
1.無法準確的知道預留字段的類型
2.無法準確的知道預留字段中所存儲的類容
3.后期維護預留字段索要的成本，同增加一個字段所需要的成本相同
4.嚴禁使用預留字段
4.反范式化設計
針對范式化而言，為了性能和讀取效率的考慮而適當?shù)膶Φ谌妒降囊筮M行違反，允許存在少量的數(shù)據(jù)冗余
空間換時間的操作
ex：符合范式的設計
反范式化的設計：
?
?
?7.維護和優(yōu)化
1..維護數(shù)據(jù)字典
1.第三方工具維護
2.利用數(shù)據(jù)庫本身的備注字段來維護數(shù)據(jù)字典。以mysql為列子
CREATE TABLE customer(
cust_id INT AUTO_INCHREMENT NOT NULL COMMENT '自增ID'
cust_name VACHAR(10) NOT NULL COMMENT '客戶姓名'
PRIMARY KEY （cust_id）
)COMMENT'客戶表'
2.維護索引
1.出現(xiàn)在WHERE從句GROUP BY從句，ORDER by從句中的列
2.可選擇性高的列要放到索引的前面
3.索引中不要包括太長的數(shù)據(jù)類型
1.索引不是越多越好，過多的索引會降低寫效率還會降低讀效率
2.定期維護索引碎片
3.在SQL語句中不要使用強制索引關鍵字
3.維護表結構
1.使用在線變更表結構的工具
MYSQL5.5之前可以使用pt-online-schema-change
MYSQL5.6之后本身支持在線表結構的變更
2.同時對數(shù)據(jù)字典進行維護
3.控制表的寬度和大小
數(shù)據(jù)庫中適合的操作
1.批量操作VS逐條操作
2.禁止使用Select*這樣的查詢
3.控制用戶自定義函數(shù)
4.不要使用數(shù)據(jù)庫中的全文索引
4.在適當?shù)臅r候對標進行水平拆分和垂直拆分
? 垂直拆分
1.經(jīng)常一起查詢的列放在一起
2.text,blob等大字段拆分出道附加表中
水平拆分
?
?
??
轉載于:https://www.cnblogs.com/bigyuanzi/p/9377583.html
總結
- 上一篇： git的团队协作开发
- 下一篇： [转]MySQL Explain详解