給數據庫表列取一個好的名字

　　做父母的總希望給自己的子女取一個響亮的、富有含義的名字。有時候家長為了找到一個合適的名字，會拿起平時碰都不碰的漢語大辭典翻個好幾天。天下父母心呀。其實在數據庫中創建對象時，管理員也要對其進行命名。

　　其實在數據庫中創建對象時，管理員也要對其進行命名。一些有經驗的數據庫管理員，對其命名也會小心翼翼。既要能夠叫的響亮，又要能夠代表具體的應用場景。有時候對表等數據庫對象進行命名的時候，可能比維護數據庫還要傷腦筋。筆者對此就有非常深的感受。在數據庫設計的時候，一套命名規則編制下來，腦袋就會覺得很累。不過等大家多編制幾套后，就會掌握其中的規律。熟能生巧，掌握了規律再去取名的話，就會簡單許多。有時候甚至可以信手拿來。筆者這次就跟大家分享一下對數據庫對象進行命名的一些規律。簡單起見，筆者以數據庫對象表為例，談談命名的一些技巧。

　　一、牢記命名空間

　　在Oracle數據庫中，跟其他的數據庫不同，有一個叫做命名空間的概念。在同一個命名空間中，其名字不可以重復。如表與視圖就共享同一個命名空間，為此就要求不僅表的名字不能夠相同，而且表的名字與視圖的名字也不能夠相同。因為他們處于同一個命名空間。類似的，表與函數也是同處于一個表空間，為此他們也不能夠同名。不過表與索引、表與約束等等卻屬于不同的命名空間。也就是說，表的名字可以與約束的名字相同。所以說，數據庫管理員在給表等對象命名的時候，一定要了解哪些對象共享同一個名稱空間。如果在同一個名稱空間內的，即使對象不同（如視圖與表），但是他們仍然不能夠取相同的名字。

　　為了避免同一個命名空間內重名的現象，筆者建立在命名的時候最好能夠根據對象的不同加上對象的固有前綴。如大部分的數據庫管理員，在給表取名的時候，一般不會表名前面加上表對象的前綴。但是在定義函數或者視圖對象的時候，則會加上前綴。如在函數前面可能會加上FN的前綴，而在視圖前面可能會加上vi的前綴。如此的話，在同一個命名空間內也不用擔心對象重名的問題。不過無論怎么說，這個命名空間的概念數據庫管理員必須牢記。即使在實際的工作中，可以通過前綴等手段輕易的避免這個陷阱，但是在Oracle數據庫管理員的認證考試中，這個命名空間也是一個必要的知識點。所以無論從實際的工作還是認證考試的需要，對于這個命名空間管理員都必須要有一個清晰的認識。

　　二、表名大小寫的控制

　　一般情況下Oracle數據庫中的表名或者列名是不區分大小寫的。在創建表或者列的時候，即使管理員采用了小寫的名字，數據庫在將其保存到數據字典之前，會先將其轉換為大寫，再將他們保存到數據字典中。這也就是為什么我們命名使用小寫的子母命名，但是下次查看表的名字的時候，卻變成了大寫。

　　雖然說Oracle數據庫中表與列等數據庫對象對于大小寫是不敏感的，但是如果數據庫管理員確實有需要要讓數據庫系統對表的名字區分大小寫，這也是可以做到的。通常情況下，如果把名字使用雙引號括起來，則在Oracle數據字典中就會成為區分大小寫的名字。不過筆者這里要提醒各位數據庫管理員，雖然說從技術上可以讓數據庫系統強制取分大小寫，但是在實際工作中，包括在內的絕大部分數據庫管理員可能都不建議這么做。因為如果有混合的大小寫存在，那么在引用這些表或者列名稱的時候就需要特別的小心。因為即使用戶或者數據庫管理員有著過目不忘的本領，也很難準確的記住這些名稱的大小寫歌時。如果數據庫管理員硬要這么做的話，那么很可能是自尋煩惱。在查詢時或者其他作業時，要嚴格區分大小寫那是一件很頭疼的事情。為此，對于這個大小寫的控制，筆者建議數據庫管理員要謹慎使用。除非有充分的理由，否則的話，不要輕易使用這個雙引號來控制大小寫。

　　這個雙引號不僅可以用來控制大小寫，還有一個比較特殊的作用，就是用引用一些特殊的字符。如在建立表格的時候，需要設置一個名牌號的字段。有些數據庫管理員習慣使用num#類似的名稱。這不會違反數據庫的命名規則。不過在處理的時候會比較麻煩。如利用create語句建立表格的時候，需要給這個字段名稱加上雙引號。否則的話，執行這條語句的時候，數據庫會拒絕執行并向用戶提示錯誤信息。類似的特殊符號還包括一個$美元符號。他們在建立表格的時候，在語句中都需要使用雙引號。不過字段建立好之后，在引用這些對象的時候，不需要使用雙引號了。同理，雖然Oracle數據庫支持這些特殊符號，但是筆者不鼓勵數據庫管理員在表或者列的命名中采取這些特殊的符號。這有可能給后續的引用帶來不必要的麻煩。

　　三、在表、索引、約束、列之間設置密切的聯系

　　在創建表的同時，可以給表中的某些列添加索引、約束等等。如在員工信息表中，會設置員工編號唯一性約束。在創建約束的時候，也需要對約束進行命名。雖然說也約束與表、列不屬于同一個命名空間，所以在取名的時候基本上沒有限制。但是為了后續使用的方便，筆者對約束的命名還有一個小小的建議。簡單的說，就是給一個與表直接有關的其他對象具有該表的名字是一種好的做法。如現在有一張用戶表名字叫做ad_user（在表名前面一般不加對象名，但是可以根據應用軟件的模塊設計加上模塊的前綴），這種表中有一個字段叫做叫做vlaue，用來存儲員工的編號。在表設計的時候，需要給這個字段加一個索引。那么這個索引的名字就可以取名為IDX_USER_VALUE（也就是索引前綴+表名+字段名的形式）。這么做有什么好處呢？一是可以確保相關對象的名字不會重復。因為表的名字不會重復，所以將表的名字與列的名字一起組成某個對象的名字，那么其重復的幾率可以說基本上沒有。二是方便管理員閱讀、理解、維護等等。一看到索引或者約束對象的名字時，就可以看到這個是索引或者約束是用在哪個表的那個字段上的。而且也可以知道這個約束是唯一性約束還是檢查約束；索引時主鍵索引還是外鍵索引。給數據庫管理員一目了然的感覺。這對于后續的維護、升級、調整、引用等等都提供了方便。 銀行招聘網－全國最大教育類網站(www．Examda。com)

　　四、讓表名與列名反應該表與列的含義

　　有些數據庫在設計的時候，給表與列取名的時候采用的是阿拉伯的隨機數字。如1111、1112等等。這雖然便于擴展，但是筆者并不贊同這種命名方法。因為此時數據庫管理員在工作的時候，旁邊還不得不有一份對象名與實際內容對應的一份表格。這操作起來非常的麻煩。有些管理員也許會說，可以通過同義詞功能來為這些表取具有一定含義的別名呀。這對于數據庫規模比較小的應用，如總共只有幾十張表格，或許是可行的。但是如果有成千上百張表格，這個定義同義詞的作業就比較累人了。所必這認為這是的得不償失的。在給表或者列命名的時候，最好能夠反映該表與列的含義。

　　另外有時候對表進行命名的時候，還需要考慮應用軟件的設計。因為程序開發人員需要引用數據庫中的對象。所以在命名時也需要考慮到他們的便利。筆者建議如果應用軟件考慮到模塊化設計的時候，如將一個應用軟件分為銷售、生產、采購、倉庫、財務等模塊時，那么各個模塊在數據庫中對應的表最好加上相關的前綴。如此的話，無論是數據庫管理員還是程序開發人員，在使用這些表的時候，都可以通過前綴來縮小其選擇的范圍。從而提高其工作的效率。只要在應用程序設計時規劃好模塊，然后為每一個模塊取一個簡單易懂的前綴（最好具有相同的字符數），就可以了。這一點小小的改進，就可以為后續使用這些數據庫對象提供很大的方便。為此筆者強烈建議讓表名反應表的用途，反應應用軟件的設計思路。

　　更多會計證考試信息請訪問：（）