在開發過程中，我採用多分節數據表命名方法(下劃線命名法）。從實踐來看，望文生義，維護效率很高，自己開發時，我很少看文檔。
一. 關於大小寫
因爲在編寫軟件過程中，會遇到很多語句會直接輸入sql語句，所以應該作到全部表名，字段名小寫。偶爾見到有的人把字段的開頭用大寫，但是在不區分大小的時候沒問題，在區分大小寫時，簡直就是絆腳石。
我們可以看sql2000的master表。
二。命名方法
1. 表命名方法
主要分連寫法和下劃線兩種方法。
連寫法
如： sysindexkeys，sysfilegroups這適合於較小的數據運用項目，這樣命名簡短使用，編寫sql語句時比較方便。但是在稍微複雜的按模組分類的系統中就顯得力不從心了，因爲涉及到多分層，連續拼寫的英文會比較模糊。並且層次感不強。在強制小寫的情況下，匈牙利命名法顯得無奈。
在不區分大小寫的情況下，駱駝式和pascal命名法失效了。這種方法不適合超過50張表的系統。
下劃線法
這種方法我在使用中是按[模組]+[子模塊]+[表名]+[附加項]
可以看出明顯的層次結構。缺點就是比較長，但是你可以在分模塊時，定義一些明確的縮寫，來強制使用。
比如設計一個用戶表，然後這個表還有多個外鍵表。我是如此命名的：
cust_info
cust_info_city(fk) cust_info_area(fk)
cust_info_modified cust_info_deleted cust_info_stop
這裏有個原則，就是主要的表儘量要短，因爲使用頻率很高。而Fk表我是用dw作成通用件，在需要的欄位用dddw方式展示。
這種方法適合系統不大，細化程度不高的情況。因爲如果細化程度很高，在cust_info的層次上還會有多種細分層次(如cust_info_modified cust_info_deleted )，所以命名就會增加到四節。就太長了。而且系統升級頻繁的話，命名也存在歧義。比如cust_info_city(fk) 還有外鍵的話。(當然對於一些fk表，一般是char(2)+varchar(16)，或者smallint+varchar(16)，我們變通的做法是集中在一張表裏，外加一個tabName字段來區分(tab+id+description)。然後在作fk的dw時，where條件裏區分開不同表的FK即可(select id,description from fk_table where tab="tabname")。我認爲是最好的方法。
當然我還見過正規的數據庫，它沒有采用這種字母的分節方法，而是採用模組+數字方式，但原則還是分節，只是更具有系統性。比如INV00100100101，字母在這裏起到分模組的標識作用，而後面的數字分四節，而且前三層可以命名999個子模塊，最後一節可以命名99張表。可以知道，這是大型系統採用的最好方法。在數據字典的強制作用下，設計和編寫都會很規範。並且擴充容易。不容易混亂。對ERP系統等，是最好的方法。(最後的兩位用於某表專署的外鍵或資源等)
這種方法適合table數量在300以上的系統，即使有1000張表也不存在任何問題。一般的ERP系統在500張表以上。是很複雜的，分模組，模塊就顯示必要。
對於procedure命名，同樣實用。因爲存儲器存在系統存儲器，所以首節最好區分開。我實用pr來分開(系統是sp_)。
2. 字段命名
2.1常規命名法
我的原則，儘量短，不用下劃線。並且強制規範化。要縮短長度，必須考慮簡寫。如provider,customer,information,這些必須考慮全局強制統一簡寫法如：prv,cust,info。而對於常用的結構性描述詞，則需全局通用化，比如userid,name,city,town,account,amount,type,class,area,country等。都是簡短有用的，望文生義的詞，不必要縮寫。在不同的表裏儘量強制統一。不要出現雜亂的局面。
字段名如果使用下劃線，在編寫sql語句時非常討厭。因爲表名尚且可以用別名，而字段名沒法偷懶。
2.2. 醜陋的命名法
拼音命名法，數字命名法是很醜陋的。要杜絕
2.3.漢字命名法
在針對報表，導出數據臨時表等非關鍵部分，可以採用漢字命名字段名，也是可以接受的。比如我在項目中有時設計到某個字段用漢字描述都很難理解，試想要用英文來命名更若天書，乾脆就用了漢字命名。但是要遵守一下匈牙利方法，比如：客戶代號，客戶名稱，客戶地址，費用應收產成，費用應收折後。太隨意跟拼音命名法就沒區別了。
