管理好ORACLE資料表的幾個建議

作者：IT專家網 Victor  2008-06-23

【IT168技術分析】ORACLE資料庫中，表是最基本的內容。可以說，表設計的好壞直接跟資料庫的效能相關。所以，在設計表的時候，除了要遵循其固有的資料庫準則之外，還需要看個人的資料庫管理經驗。下面我就把這些經驗分享一下，或許對大家有所幫助。

　　一、 表該存放在哪裡?

　　我們都知道，在ORACLE資料庫中，使利用空間這個概念來管理表物件的。在資料庫建立的時候，資料庫中已經建立了一些表空間。那麼當我們新建立表的時候，這個新表的位置該放在什麼地方呢?這就好像吃飯時的坐的位置一樣，是有講究的。一般來說，我們在新建表的時候，至少要遵循如下建議：

　　一是在資料庫建立的時候，在資料庫中已經有了一個SYSTEM的表空間。一般情況下，這個表空間中，只包含資料字典及Oracle系統物件。如果我們將我們的表建立在這個空間上的話，那是要降低資料庫的效能的。所以，一般我們是不建議使用者把表格建立在這個空間上。但是，若我們不只一個人維護資料庫，如有八個人共同設計資料庫系統時，如何才能保證其他使用者不在SYSTEM表空間中建立資料庫表格呢?最好的辦法就是通過許可權控制。如我們可以給每個資料庫設計人員指定一個預設的表空間，讓他們只能在這個表空間中建立表格。如此的話，就能防止他們在SYSTEM表空間中建立自己的資料表格，從而對資料庫的執行效能產生不良影響。所以，若給每個使用者設定預設表空間的話，那麼使用者在建立具體的表時，不用具體指定表空間了。

　　二是我們在為某個應用設計資料庫的時候，最好先對錶的空間進行規劃。一般情況下，不要把資料表隨意的分散到不同的表空間中去。如我們在為一個ERP系統設計資料庫的時候，若把採購部門相關的表跟銷售部門相關的表放到兩個不同的表空間中去，這是不明智的做法。這麼處理的話，會降低某些資料庫管理和維護操作的效率，如資料的備份與恢復操作;而且，也無法集中管理屬於某個特定應用的資料。所以，我們一般建議，在規劃資料庫表空間的時候，把相同應用的表放在同一個表空間中去。如果要區分不同部門或者不同模組的表的話，我們可以在表的命名上動腦子。如我們在設計ERP系統的資料庫中，可以根據其應用模組的不同，在前面加上字首來進行識別。如跟系統基本配置相關的表，我們可以用AD為字首;而跟銷售部門相關的表，我們可以加上SA字首等等。如此的話，這些表具體是屬於哪個模組的，就一清二楚了。完全沒有必要為此設定不同的表空間。這是ORACLE資料庫初學者經常會犯的錯誤。主要是對ORACLE表空間的定義不是很熟悉所導致的。

　　二、 對預計儲存數量比較大的表時，要給與額外的重視。

　　有些表非常的大。我們這邊說的大，不一定是說結構複雜，而是指在這個表格中，預期會儲存比較多的資料。為了提高對這個表格的處理效率，我們在事先要做出一定的安排。否則的話，後續對這些大表進行查詢、插入等操作的話，速度會很慢。所以，我們就有必要在資料庫設計的時候，先預先估計一下表的資料儲存量，把一些資料量大的表格，做一些額外的設定。如在ERP軟體的資料庫設定中，一般來說，產品資料與物料清單資料這兩個表的資料量會比較大;而從長遠看的話，銷售訂單、採購訂單、生產訂單、記賬憑證等這種單據類相關的表格其資料量也會比較大。一年兩年可能感覺不出來，但是，到十年後，這個紀錄數量就會很龐大。而像ERP系統這種大型的資訊化管理專案，用個幾十年時很正常的事情。而且，為了記錄的完整性，也不建議使用者把以前的資料刪除。所以，為這種應用進行資料庫設計的時候，要充分考慮這些大表的效能問題。

　　具體的來說，設計大表的時候，可以考慮遵循如下的建議。

　　一是不要為大表設定儲存的限制。在ORACLE資料庫中，可以為每張表格設定儲存配額限制。如此的話，表最大容量就不能超過這個限制。對於一些資料容量比較小的表格，這麼設定時合理的，可以提高空間的利用率。但是，若資料量比較大的話，就不建議事先設定表的儲存空間了。如ERP系統的銷售訂單表，其剛開始可能記錄量很小，第一年預計只有1G的記錄容量，但是，估計在十年後，這個記錄容量就會達到10G了。在這種情況下，我們怎麼來給其設定儲存空間呢?一開就設定10G空間，這也是不合理的。而且，設定儲存空間，就意味著有可能產生儲存碎片，從而影響到資料查詢的效率。所以，在資料庫表的設計過程中，若某些應用的表可能會有比較大的資料容量時，建議不要對其儲存空間做出任何的限制。

　　二是要為這大表分配足夠的臨時空間。如我們使用ERP系統時，要查詢產品資料資訊。我們都知道，產品資訊的話，有些企業這個紀錄數非常的龐大。而且在查詢時，我們還會經常的進行排序操作。如有時候會按照產品編碼對查詢出來的資料進行排序。當記錄少的話，還好;但是，當記錄多的話，這個排序動作，要求具有比較大的臨時儲存空間。所以，當某個表預計會有很大的記錄數量的時候，我們就要給其分配足夠多的臨時空間。臨時空間的儲存引數設定取決於臨時表空間的預設儲存引數設定。我們可以更改這些引數，以達到我們對要求。若沒有給大表分配足夠多的臨時空間的話，則排序的動作將會很慢，而且很可能不成功。

　　三是要考慮將表與表的索引分離存放。大表所對應的索引通常也比較大。一般來說，索引的數量是隨著表記錄的數量增加而增加，兩者是接近於一個正比例的關係。所以，通常表的記錄容量大的時候，索引數量也會很龐大。針對這種情況，我們考慮突破我們上面講的表空間的規則定義。而考慮把表和他的索引分別儲存於不同的表空間中，甚至在條件允許的情況下，分別儲存於不同的硬碟中。這麼做的好處是什麼呢?最大的好處是讓索引比較容易的獲得所需要的連續的儲存空間，從而提高輸入輸入的效率。通俗的說，就是可以提高資料的查詢效率。如不這麼處理的話，查詢大容量的記錄的話，資料庫可能需要花費30秒;而如此設計的話，就可能把時間縮短為10秒。這是一個很明顯的效能改善。

　　三、 如何給表命名?

　　上面我在講如何為表分配儲存空間的時候，已經講到過這方面的問題。下面，我就將對這個問題進行詳細的描述，以幫助資料庫管理員掌握一套好的資料庫命名規則。

　　首先，毋庸置疑的，在為標命名的時候，要遵循ORACLE資料庫的基本命名規則，如不能以數字開頭為表命名，如不能利用資料庫的關鍵字為表命名，如表的名字不能重複等等。這些是最基本的要求，就不用我多費口舌了。除了要遵循這些基本的命名規則外，在實際工作中，為了資料庫後續的維護等方面出發，我們還是要遵循一些額外的規則。這些規則跟ORACLE定義的規則不同。我們所講的規則沒有約束力，可以說，只是業界的一些共識而已。你若不怎麼處理，ORACLE資料庫也不會說你錯誤，只是後續維護的時候，會比較麻煩而已。

　　一是在對資料庫命名的時候，最好能跟體現表的分類關係。如最常見的，我們在設計資料庫的時候，表都是按系統的具體模組來區分的，如根據前端系統要求的不同，資料庫的表大致可以分為系統基本配置表、銷售模組表、採購模組表、報表模組表等等。我們可以根據這些模組的不同，分別給與不同的字首來區分。這麼做的好處是很明顯的。如一看到表最大名字，就可以知道這個表是屬於哪個應用的、哪個模組的，這無疑可以提高資料庫設計與前臺軟體開發的效率。同時，資料庫中預設的排序規則是按名字來排序的，所以，為表格設定類別字首的話，可以把同一類的表格排在一起，方便我們察看。

　　二是對錶格命名的時候，要考慮可讀性，而不能隨便阿狗阿貓的亂取名字。最常見的是，那些剛學資料庫的人，在表命名的時候，如要建幾張測試表，就會隨便命名如TEST1，TEST2之類的。雖然這只是測試，但是，也不符合我們的命名過則。要做測試的話，那就以TEST開頭，然後後面加上具體要測試的內容。如此的話，我們才可以通過表的名字知道該表具體的用途。而不用開啟表去看裡面具體的結構或者註釋才能知道我們需要的資訊。所以，在設計表的名字的時候，還要關注一下其的可讀性。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7656893/viewspace-374318/，如需轉載，請註明出處，否則將追究法律責任。