oracle數據庫設計規(guī)范建議(編輯修改稿)
2025-05-04 06:23 本頁面
【文章內容簡介】 索引前后的查詢速度；索引對性能會有一定影響，對于DML頻繁列的索引要定期維護（重建）。但是，索引的結構對于索引的更新（比如在插入數據的時候）是有一定優(yōu)化的，所以不要在沒有試驗以前過分夸大它對性能的影響。最終還是以試驗為準； 不要建實際用不上的索引，與上條相關，如果建的索引并不提高任何一應用中的查詢速度，則要把它刪除；有些數據庫有相關工具可以發(fā)現實際未被使用的索引，可以利用一下； 索引類型的選擇：要根據數據分布及應用來決定如何建立索引，一般的高基數數據列（高基數數據列是指該列有很多不同的值）時 ,建立BTree索引（一般數據庫索引的缺省類型）；當低基數數據列（該列有大量相同的值）時，可以考慮建立位圖索引（如果所選數據庫支持的話），但位圖索引是壓縮類型索引，所以DML（增、刪、改）的代價更高，要綜合考慮； 索引列的選擇：如果檢索條件有可能包含多列，創(chuàng)建聯合主鍵或者聯合索引，把最常用于檢索條件的列放在最前端，其他的列排在后面；不要索引使用頻繁的小型表，假如這些小表有頻繁的DML就更不要建立索引，維護索引的代價遠遠高于掃描表的代價； 主鍵索引在建立的時候一定要明確的指定名稱，不能讓系統(tǒng)默認建立主鍵索引（可能有些數據庫無法指定主鍵名，則例外）； 外鍵必須需建索引。當有一定數據量，并且經常以外鍵所在列為關聯，進行關聯查詢時，需要建索引（可能有些數據庫自動為外鍵建索引，則例外）； 當有聯合主鍵或者聯合索引時，注意不要建重復的索引。舉例說明： 表EMPLOYEES，它的主鍵是建立在列DEPARTID和EMPLOYEEID上的聯合主鍵，并且創(chuàng)建主鍵的語句中DEPARTID在前，EMPLOYEEID在后。在這樣一個表里，通常就沒有必要再為DEPARTID建一個索引了；聯合索引的情況也一樣； 更復雜的情況，比如表EMPLOYEES，有一個索引建立在列CORPID, DEPARTID, EMPLOYEEID三列上，在創(chuàng)建語句中也依據上述順序，就沒有必要再為CORPID建立索引；也沒有必要再建立以CORPID在前，DEPARTID在后的聯合索引；如果EMPLOYEEID需要索引，那么為EMPLOYEEID建立一個索引是不與上面的索引重復的；DEPARTID列也類似； 控制一個表的索引數量，盡量使得一個表的索引數量小于五個； 視圖的設計 在不太清楚視圖用法的情況下，盡量不建。因為一旦建了，就有被濫用的危險； 如果需要建視圖，只要是打算長期使用的，請寫入數據庫設計中。明確它的用途、目的； 建立視圖時要明確寫出所有要選擇出的列名而不要以SELECT *來代替，可以使結構清晰可讀性增強，也不會增加它對表的所有字段的依賴，而表是很可能修改的，特別是增加字段。就很有可能導致使用該視圖的應用程序出錯； 存儲過程、函數、觸發(fā)器的設計 觸發(fā)器的功能通常可以用其他方式實現。在調試程序時觸發(fā)器可能成為干擾。假如你確實需要采用觸發(fā)器，一定要經過測試再應用在生產系統(tǒng)中，而且必須集中對它文檔化。 請把程序包、存儲過程、函數、觸發(fā)器，與應用程序一同加入CVS中，進行版本控制。因為此四者包含了代碼，應用程序對他們的依賴程度比對表、視圖的依賴程度更高； 適量但盡量少使用存儲過程、函數、觸發(fā)器。使用存儲過程、函數、觸發(fā)器的影響：(1) 可以減少數據庫與客戶端的交互，提高性能；(2) 有的數據庫還對他們進行了某種程度的編譯，在執(zhí)行的時候，不用再對其中的SQL等語句進行解析，從而提高速度；(3) 如果
公司管理相關推薦
鄂ICP備17016276號-1