注意:數據庫
一、事務多時選Oracle。併發
二、SQLserver只支持在Windows下運行。數據庫設計
三、開發用的語言用的.net時,使用SQL server。函數
MySQL是開源數據庫,只要知足存儲協議,高併發
讓開發團隊明確數據庫的定義。全部對象命名應該遵循下述原則:性能
一、可讀性原則大數據
使用大小寫來格式化的庫對象名字以得到良好的可讀性。優化
例如:使用CustAddress而不是custaddress來提升可讀性。網站
二、表意性原則spa
對象的名字應該可以描述它所標識的對象。
例如,對於表,表的名稱應該能狗體現表中存儲的數據內容;對於存儲過程,存儲過程的名稱應該可以體現存儲過程的功能。
三、長名原則
儘量少用或者不使用縮寫,適用於數據庫(DATABASE)名以外的任一對象。
根據所選的DBMS系統選擇合適的字段類型。須要存儲字符串,須要用什麼作存儲。
列的數據類型影響:
一、數據存儲空間的開銷。
二、數據查詢性能。
選擇原則:當一個列能夠選擇多種數據類型時,應該優先考慮數字類型,其次是日期或二進制類型,最後是字符類型。對於相同級別的數據類型,應該優先選擇佔用空間小的數據類型。
以上選擇原則主要是從下面兩個角度考慮:
一、在對數據進行比較(查詢條件、JOIN條件及排序)操做時:一樣的數據,字符處理每每比數字處理慢。
二、在數據庫中,數據處理以頁爲單位,列的長度越小,利於性能提高。
MySQL:16K/頁
MySQL時間戳timestamp有限制:只能存儲到2037年。
1、char與varchar選擇
原則:
一、若是列中要存儲的數據長度差很少是一致的,則應該考慮用char;不然應該考慮用varchar。
二、若是列中的最大數據長度小於50byte,則通常也考慮用char。若是這個列不多用 ,則基於節省空間和減小I/O的考慮,仍是能夠選擇用varchar。
三、通常不宜定義大於50byte的char類型列。
MySQL:utf-8:1字符=3字節。
2、decimal與float選擇
原則:
一、decimal用於存儲精確數據,而float只能用於存儲非精確數據。故精確數據只能選擇用decimal類型。
二、因float的存儲空間開銷通常比decimal小,非精確數據優先選擇float類型。
(精確到7位小數只須要4個字節,而精確到15位小數只須要8字節)
3、時間類型如何選擇
一、使用INT來存儲時間字段的優缺點:
優勢:字段長度比datetime小。Datetime:8個字節,int:4個字節。
缺點:使用不方便,要進行函數轉換。
限制:只能存儲到2038-1-19 11:14:07即:2147483648
舉例:1)生日:使用地方不多時,能夠考慮用int來存儲。
2)下單時間:因爲常常要查詢到,要用時間判斷,用datetime存儲。
二、須要存儲的時間粒度
年:year:1字節
月:
日 時分秒 周
1、如何選擇主鍵
一、區分業務主鍵和數據庫主鍵
業務主鍵用於標識業務數據,進行表與表之間的關聯;
數據庫主鍵爲了優化數據存儲(Innodb會生成6個字節的隱含主鍵)
二、根據數據庫的類型,考慮主鍵是否要順序增加
有些數據庫是按主鍵的順序邏輯存儲的。不會進行邏輯遷移,對I/0有好處。
三、主鍵的字段類型所佔空間要儘量的小
數據庫按頁來存儲數據的,主鍵越小,頁中查詢的主鍵就越多,能夠裝載更多的數據,對I/O性能有好處。對於使用匯集索引方式存儲的表,每一個索引後都會附加主鍵信息。
2、避免使用外鍵約束
外鍵:保持數據完整性的一種方式,在高併發的互聯網站中,有必定影響。
一、下降數據導入的效率:對於數據的導入或寫入操做時,當使用了外鍵時,每寫入一條數據都會查詢是否符合外鍵約束,若是符合才能插入數據,不符合被拒絕掉,耗時間。在高併發時影響大。
二、增長維護成本
三、雖然不建議使用外鍵約束,可是相關聯的列上必定要創建索引。
3、避免使用觸發器
使用觸發器減小程序上的邏輯處理。
一、下降數據導入的效率
二、可能會出現意想不到的數據異常
三、使業務邏輯變的複雜。當程序變動,別人不知道這塊有觸發器的時候,改邏輯時會出現業務異常。
4、關於預留字段
一、沒法準確的知道預留字段的類型。
二、沒法準確的知道預留字段中的所存儲的內容。
三、後期維護預留字段所要的成本,同增長一個字段所須要的成本是相同的。
四、嚴禁使用預留字段。
在一些表中,增長一些冗餘。
反範式化是針對範式化而言的,在前面介紹了數據庫設計的第三範式,所謂的反範式化就是爲了性能和讀取效率的考慮而適當的對第三範式的要求進行違反,而容許存在少許的數據冗餘,換句話來講反範式化就是使用空間來換取時間。
好處:一、減小表關聯數量。二、增長數據讀取效率。三、要適度。
舉例: