oracle 數據庫 設計 規範

一

1.  先創建邏輯模型，也就是ER圖  ，再映射爲物理模型。

2. 關於範式， 標準化數據模型通常都不是最終的結果，但他始終是建模最好的起點。

鍵，完整的鍵，除了鍵沒有其餘東西。

3. 關於數據類型的選擇。

因爲oracle在數據類型的物理存儲上採用很是靈活的方式，所以從存儲和性能考慮，使用限制性很強的數據類型或者精度 並無優點。

 

二

選擇數據類型時，要注意如下方面：

1.大部分狀況下，無論你如何限制數據類型，Oracle內部都會使用大範圍高精度的浮點方式進行存儲，針對於數字和日期。

就算你給一個數字指定了精度，這個精度更多的意義在於約束數據或定義文檔，而不是爲了優化性能。

也有例外的狀況，就是精度可以減小數據的長度，就會有利於性能的提升。

 

2.固定長度的字符串都會佔用一個固定長度的存儲空間。 採用固定長度能夠下降碎片，可是可能會致使較大的平均行長，致使全表掃描開銷加大。

所以，除非你十分肯定字符串的長度是肯定的，好比MAC地址，不然你就應該選擇變長字符串類型。

 

3 varchar在11g以後所有用varchar2替代，現階段 2者是同樣的。

 

4. 對於大文件，推薦使用 lob類型。  Blob   二進制， Clob  文本，bfile   外部儲存。

 

三 關於人造建：

人造鍵一般會比天然鍵帶來更好的性能。

他一般由一個數字類型構成。

相比天然鍵，會減小錶鏈接的開銷和索引查詢的開銷。

 

邏輯模型不要一對一映射到物理模型，邏輯主要考慮功能的實現，物理 主要考慮 性能和儲存方式，，這樣能夠大大節約之後調優的時間。！！

 

四  關於表類型的選擇

後談

 

五  關於null 值

普通索引不要存null，null不會走索引，只能全表掃。

 組合索引 和位圖索引能夠儲存null。

採用null能夠下降行的平均長度，從而必定程度上提升全表掃描的性能。

將查詢null 更改成查詢一個默認值，就是爲了走索引。！！

null值的儲存須要一個字節的儲存空間。

 

六 列的順序

訪問靠後的列，比靠前的列 須要額外消耗少許的CPU資源。 基於此，把常常訪問的列放到前面會帶來少許的性能提高。

 

七 反規範化

1. 複製列值

主要爲了不使用錶鏈接進行查詢。

 

 

三  物理方面

物理存儲方案

1. 當往表中插入新紀錄的時候，oracle須要掃描空閒數據塊鏈表。 ASSM 可以自動的很好的完成 空閒數據快鏈表 以免 鏈表爭用。針對對插入事務頻繁的表。

 

2. 經過合理設置pctfree 來避免行遷移。數據走，留指針。

 

3. 在一個事務更改一個塊的時候，會得到事務槽，若是事務槽沒法自動增長分配，那麼事務將會等待。

 

4，數據壓縮，基本都是說的可以提升全表掃描的性能，個人理解是對於範圍掃描，也能夠提升性能。 字符串的壓縮率大於數字類型，對磁盤中數據的壓縮收益要大於對內存中數據的壓縮。

 

5 關於lob

通常儲存超過4000字節的數據，不然用varchar2來儲存。 一般狀況下，Lob數據不會跟同一行記錄的其餘列儲存在相同的數據塊中，只有lob對象不到4000 ，才inline儲存。

控制方式： enable/disable storage in row。

若是LOB字段是常常須要訪問的字段，那麼建議仍是採用inline儲存。由於訪問外部儲存 的lob須要額外的IO。

 

請設置db_securefile參數， 能夠將新的lob列的默認儲存方式設置爲 secure file。

 

6 關於分區

 

分區主要在與2點， 分區消除，便於管理歷史分區數據而不影響當前分區。

 

關於設計原則，就是以上內容，轉載：http://blog.csdn.net/familyrun/article/details/47037393

 

關於細節規範：

1. 若是開發過程當中須要創建索引，須要提交書面的更改請求，說明所需索引的定義(名稱、字段列表、順序、索引類型)以及創建的理由。數據庫管理員統一維護索引並將提交的請求更改。
2. 數據庫各表的初始數據(包含各代碼表、配置表)須要提交給數據庫管理員。
3. 不得使用觸發器。
4. 涉及到數據庫多表數據的更改(Insert/Delete/Update)必須使用數據庫事務進行控制，而且必須有完整事務開始和提交/回滾機制。不能使用範圍事務
5. 儘可能避免Union操做的使用，須要使用時，請向數據庫管理員諮詢使用Union操做的影響。
6. SQL語句和存儲過程，儘可能使用PL/SQL Develper的代碼美化器美化。
7. 屬於ORACLE的關鍵字大小，表名、列名等小寫。