IDC表設計規范說明_第1頁
IDC表設計規范說明_第2頁
IDC表設計規范說明_第3頁
全文預覽已結束

下載本文檔

版權說明：本文檔由用戶提供并上傳，收益歸屬內容提供方，若內容存在侵權，請進行舉報或認領

文檔簡介

1、.數據庫表設計規范目的為了規范數據庫設計，減少設計失誤，提高數據安全及性能，特制訂本規范。適用范圍適用本系統 MySQL數據庫。原則上，數據庫設計應遵循本規范說明，特殊情況可例外，但需說明原因。規范命名1.庫名、表名、字段名必須使用小寫字母,命名有需要的話采用下劃線分割2.庫名、表名、字段名禁止超過32個字符3.庫名、表名、字段名支持最多64個字符 ,但為了統一規范、易于辨識以及減少傳輸量,禁止超過 32個字符。4.庫名、表名、字段名禁止使用MySQL 保留字表1.減少或避免使用臨時表；2.每一個表都需要設置主鍵3.表沒有主鍵 ,INNODB 會默認設置隱藏的主鍵列;沒有主鍵的表在定位數據行的

2、時候非常困難,也會降低基于行復制的效率。范式1.表不要求一定滿足第三范式，根據實際情況可適當添加冗余字段。2.我們的原則是一個SQL 最好只操作一個表，最多不能超過3 個表的關聯。如果實現一個常用的功能需要一個關聯多表的查詢，則需要重新考慮設計。3.由程序保證冗余數據的維護。'.約束1.對于字典類型的表，因數據量小，修改少，影響面大，應依賴數據庫約束來確保數據質量。2.對于日志或流水型表，為了提升效率，可以釋放放寬限制。之所以分開，是從性能以及影響面考慮的。對于字典類型的數據，因為修改少，約束給其性能帶來的負面影響忽略。但是一個數據字段的數據錯誤，影響面非常廣，因此，需要非常嚴謹。前段

3、程序或者手工添加此類數據時，容易出現錯誤，因此需要通過約束來保證其數據的質量。日志或者流水型表剛好相反，它一般只影響個別用戶，但數據量較大，修改較為頻繁，性能優先。字段1.對于字段設計，概況下來一個原則是：越簡單越好，越小越好。2. 選擇最合適的數據類型，能用數字類型不用varchar 類型；能用 date/datetime 類型不用 varchar類型；避免使用char 類型；不使用浮點數，可以通過乘以一個系數來轉換為整型數據。3. 字段長度定義遵循最小化原則，夠用就行，不能貪圖方便定義很大的長度。過大的長度容錯性高，容易出現低質量數據。4.一個表的字段個數控制在30-50 個字段以內；如果字段超過50 個，可考慮將字段按冷熱程度分表。這樣做雖然會給應用帶來更多的代碼開發量，但對于熱表來說，這樣做可以提升buffer 利用率，減少IO，提升查詢的效率。每一個重要的業務表都加上create_time和 isDel 兩個字段，數據類型為datetime 和 integer ；索引 /主鍵設計1.主鍵由一個字段構成，最多不要超過 3 個，禁止超過 3 個字段的組合主鍵。如果業務要求，則創建一個自增字段作為主鍵，再添加一個唯一索引。如果查詢都是基于主鍵字段，且只有1 個及以下輔助索引，則限制可以放寬。'.在建表時，應充分考

溫馨提示

  • 1. 本站所有資源如無特殊說明，都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等，如果需要附件，請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙，網頁內容里面會有圖紙預覽，若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間，僅對用戶上傳內容的表現方式做保護處理，對用戶上傳分享的文檔內容本身不做任何修改或編輯，并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容，請與我們聯系，我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論