數據庫技術-數據庫命名與設計規範
命名錶
在大多數數據庫中，有三種類型的表：
1、數據表（Data Tables ） - 當然，在一個數據庫中所有表包含數據，但我使用這個詞來指代實際存儲，而我們被刺激生成數據庫，開始與數據，如客戶，訂單或產品的表。例如，一個客戶表包含與如姓名，地址和電話領域的有關客戶的信息。客戶是一個數據表 - 不像其他這些表類型。
2、鏈接表（Link Tables）- 鏈接表做的無非就是連接兩個不同的數據表的兩個關鍵領域，形成許多一對多的關係。例如，你可以有一個供應商表和產品表之間的許多一對多的關係，因爲每個供應商可以支持多個產品，每個產品可以通過多個供應商進行銷售。這將需要一個第三表向賣方鏈接到的產品。
3、選擇表（Picklist Tables ） - 這是常見的有內含的選擇在數據表中的字段列表的表。例如，你可能在你的供應商表中的狀態字段。值對供應商的地位可以從另一個表中選擇。我指的是這些類型的表作爲“選擇”表，因爲它們允許用戶從列表中選擇。
在我的命名方案，我想每個前綴的表名與三個前綴之一，以指示表的類型。我用下面的前綴：
數據表 - 我用的前綴TBL 。所以，記住我的規則大小寫混合的，沒有下劃線，你可以有以下數據表：
tblCustomer
tblOrder
tblOrderEntry
tblVendor
tblProduct
鏈接表 - 我用的是前綴的鏈接。因此，與產品供應商聯繫起來，你將有一個表linkVendorProduct 。
選擇表 - 我用的前綴pltbl 。因此，對於供應商的地位，你將有一個名爲pltblVendorStatus表。如果你也有對客戶狀態的表，你可以有pltblCustomerStatus。
優點：
我發現這個表命名系統具有幾個優點。
1、顯然，這是很容易從表名告訴是包含什麼樣的數據表。
2、我所見過的（如Microsoft Access或SQL Server ），每個數據庫的應用程序，按字母順序列出你的表。使用這個前綴方案會使你的表是由類型時，按字母順序顯示分組。
3、如果你開發任何種類的自動代碼生成工具，很容易通過編程從什麼樣的數據表中包含的表名來確定。您只需檢查前綴。
單數/複數名
請注意，在上面我的數據表，所有的表名是單數，即tblCustomer而不是tblCustomers 。無論您喜歡單數或複數名稱，你應該總是使用一個或另一個一致。我更喜歡單數，因爲它似乎更清潔的給我。
其他表類型如：
記錄表（log tables）
錯誤表（error tables）
系統表（system tables）
每個這些可以有他們自己的前綴。
基本命名規則
表1. 基本數據庫對象命名
| 數據庫對象 | 前綴 | 舉例 |
|
表(Table) 字段(Column) 視圖(View) 存儲過程(Stored procedure) 觸發器(Trigger) 索引(Index) 主鍵(Primary key) 外鍵(Foreign key) Check約束(Check Constraint) Unique約束 用戶定義數據類型(User-defined data type) 用戶定義函數(User-defined function) |
無 無 v pr tr ix_ pk_ fk_ ck_ uq_ udt fn |
Student Title vActivity prDelOrder trOrder_D ix_CustomerID pk_Admin fk_Order_OrderType ck_TableColumn uq_TableColumn udtPhone fnDueDate |
關於命名的約定
變量(T-SQL編程中聲明的變量)、過程(存儲過程或觸發器等)、實體(表、字段)應該根據他們所代表的實體意義和進程作用來命名：
表2.好的命名 和 不好的命名 範例
| 好的命名 | 不好的命名 |
|
@CurrentDate @ActivityCount @EquipmentType prCalculateTotalPrice |
@D @ActNum @ET @prRunCalc |
還有一個常見的錯誤就是隻使用面向計算機的術語，而不是面向公司業務的術語，比如ProcessRecord就是一個含糊不清的命名，應該使用一個進程業務描述來替換它，比如CompleteOrder.
如果完全根據上一條的要求，那麼根據業務描述的過程名可能會變得很冗長，比如下面：
prCountTotalAmountOfMonthlyPayments (計算每月付費的總金額)
prGetParentOrganizationalUnitName (獲取上級單位名稱)
此時則應該考慮使用縮寫：
- 如果可以在字典裏找到一個詞的縮寫，就用這個做爲縮寫，比如：Mon(Monday)、Dec(December)
- 可以刪除單詞元音(詞首字母除外)和每個單詞的重複字母來縮寫一個單詞。比如：Current = Crnt、Address = Adr、Error = Err、Average = Avg
- 不要使用有歧異的縮寫(一般是語音上的歧義)。比如b4(before)、xqt(execute)，4tran(Fortran
避免無謂的表格後綴
這兩點我想大家都知道：1、表是用來存儲數據信息的。2、表是行的集合。那麼如果表名已經能夠很好地說明其包含的數據信息，就不需要再添加體現上面兩點的後綴了。
實際工作中，我看到有的同事對錶這樣命名：GuestInfo，用於存儲客戶信息。這個命名與上面所說的第1點重複，誰都知道表本來就是存儲信息(information)的，再加個Info無異於畫蛇添足，個人認爲直接用Guest做表名就可以了。
對於存儲航班信息的表，他又命名爲FlightList。這個命名又與之前說的第2點相重複，表是行的集合，那麼自然是列表(List)，加上List後綴顯得很多餘，命名爲 Flight 不是很好麼？可見，他給自己都沒有訂立一個明確的命名規則，不然這兩個表一定是要麼命名爲：GuestList、FlightList 要麼命名爲 GuestInfo、FlightInfo，而不會是兩者的混合。
多對多關係中連接表的命名
大家知道，如果要實現兩個實體間的多對多關係，需要三張表，其中一張是解析表。考慮下面這樣一個多對多關係，這是一個經典的學生選課問題：一個學生可以選很多門課，一門課可以有很多學生。此時爲了實現上面的關係，就需要一張解析表(這張表只存儲學生ID和課程ID，而學生的信息和課程信息分別存在各自的表中)，這個表的起名，建議的寫法是將兩個表的表名合併(如果表名比較長可做簡化)，此處如 StudentCourse。這個表中字段分別命名爲StudentId、CourseID(既是此表的複合主鍵，同時分別爲連接Student表和Course表的外鍵，等下到主鍵和外鍵的命名處再說)，這樣就實現了學生和課程之間的多對多關係，當然，這個關係還可以加點額外的東西，比如給StudentCourse表中加AccessLevel字段，值域D{只讀,完全,禁止}，就可以實現訪問級別。
約定俗成的字段名前/後綴
數據庫開發的時間久了，慢慢就會摸索出一個規律來：就是很多的字段都有些共同的特性。比如說，有的字段是代表時間的(例如發帖時間，評論時間)，有的是代表數量的(例如瀏覽數，評論數)，有的是代表真假類型的(例如是否將博客隨筆顯示在首頁)。對於這種同一類型的字段，應該使用統一的 前綴 或者 後綴去標識它。
我們來舉幾個例子看得更明白一點。
以大家都熟悉的論壇來說，需要記錄會員最後一次登錄的時間，這時候一般人都會把這個字段命名爲LoginTime 或者 LoginDate。這時候，已經產生了一個歧義：對於另一名開發者來說，如果僅看錶的字段名稱，不去看錶的內容，很容易將LoginTime理解成 登錄的次數，因爲，Time還有一個很常用的意思，就是次數。
爲了避免這種情況發生，應該明確的規定：所有表示時間的字段，統一以 Date 來作爲結尾。
我們經常需要統計發帖數、回帖數信息，這時候，開發人員通常會這樣去命名字段：PostAmount、PostTime、PostCount，同樣，由於Time的歧義，我們首先排除掉不使用PostTime作爲字段名。接下來，Amount 和 Count 都可以表示計數的意思，用哪個合適呢？這裏，我推薦使用Count。爲什麼呢？如果你做過Asp開發，相信一定知道 RecordCount 這個屬性，命名的時候有一個原則：就是使用約定俗成的名稱，而不要去自創名稱。既然微軟都用Count後綴來表示數目，我們爲什麼不呢？
於是，所有表示數目的字段，都應該以Count作爲結尾。將這一概念做以推廣，很容易得出，瀏覽次數爲 ViewCount，登錄次數爲LoginCount 等等。
再舉一個例子，我們很少在數據庫裏直接保存圖片等二進制數據，通常是僅保存圖片的URL路徑；在文章管理系統中，如果是轉載文章，也會用到記錄文章出處的字段。個人建議所有代表鏈接的字段，均爲Url結尾。於是，圖片路徑的字段命名爲 ImageUrl，文章出處字段的命名爲SourceUrl。
最後一個例子，我們經常需要用到布爾值，比方說，這篇隨筆要不要顯示到首頁，這篇隨筆是不是保存到草稿箱等等。同樣，按照微軟的建議，布爾類型的值均以 Is、Has 或者 Can開頭。
如果讓我來建表示是否將隨筆放到首頁的字段，它的名字一定是這樣的：IsOnIndex
類似的例子是很多的，我在這裏僅舉出典型的幾個範例，大家可以自行拓展，如果我能起到一個拋磚引玉的作用就很滿足了。
字段命名時需注意的一個問題
我發現有很多開發人員喜歡給字段加上表名作爲它的前綴，舉個例子，如果有個表叫User，那麼他就會將這個表中的字段命名爲：UserId、UserPassword、UserName、UserPhone 等等。個人認爲，這是沒有必要的，因爲你已經確切的知道了這個表存儲的是User的信息，那麼其中的字段必然是針對於User的。而且，在Join連接操作中，你的SQL代碼看上去也會更加的精簡一些，諸如 [User].UserName = Aritcle.ArticleAuthor 這樣的代碼完全可以實現爲 [User].Name = Article.Author。
這裏還存在一個特例，就是表的外鍵包含的字段。在這種情況下，我傾向於使用表名+ID 的方式，比如 CategoryId 、UserId 等。假設有表Article，那麼它的主鍵我會命名爲Id，關聯用戶表User的外鍵包含的字段，我會命名爲UserId。之所以這樣，是因爲在語言(比如C#)中創建對象時，有時候會使用代碼生成器(根據數據庫的字段名生成對象的字段、屬性名)，此時生成的代碼更規整一些。
建表時需要注意的問題
數據庫不僅是用來保存數據，還應負責維護數據的完整性和一致性
我看過很多的開發人員設計出來的數據庫，給我的感覺就是：在他們眼裏，數據庫的作用就如同它的名稱一樣――僅僅是用來存放數據的，除了不得不建的主鍵以外，什麼都沒有...沒有 Check約束，沒有索引，沒有外鍵約束，沒有視圖，甚至沒有存儲過程。
在這裏，我提出如下數據庫設計的建議：
- 如果要寫代碼來確保表中的行都是唯一的，就爲表添加一個主鍵。
- 如果要寫代碼來確保表中的一個單獨的列是唯一的，就爲表添加一個約束。
- 如果要寫代碼確定表中的列的取值只能屬於某個範圍，就添加一個Check約束。
- 如果要寫代碼來連接 父－子 表，就創建一個關係。
- 如果要寫代碼來維護“一旦父表中的一行發生變化，連帶變更子表中的相關行”，就啓用級聯刪除和更新。
- 如果要調用大量的Join來進行一個查詢，就創建一個視圖。
- 如果要逐條的寫數據庫操作的語句來完成一個業務規則，就使用存儲過程。
NOTE：這裏我沒有提到觸發器，實踐證明觸發器會使數據庫迅速變得過於複雜，更重要的是觸發器難以調試，如果不小心建了個連環觸發器，就更讓人頭疼了，所以我更傾向於根本就不使用觸發器。
以Not Null的思路建表
我發現很多開發人員在建表的時候，如果要新建一個字段，他的思路是這樣的：默認這個字段是可以爲Null的，然後去判斷是不是非要Not Null不可，如果不是這樣，OK，這個字段可以爲Null，接着繼續進行下一個字段。結果往往是一張表除了主鍵以外所有的字段都可以爲Null。
之所以會有這樣的思路，是因爲Null好啊，程序不容易出錯啊，你插入記錄的時候如果不小心忘輸了一個字段，程序依然可以Run，而不會出現 “XX字段不能爲Null”的錯誤消息。
但是，這樣做的結果卻是很嚴重的，也會使你的程序變得更加繁瑣，你不得不進行一些無謂的空值處理，以避免程序出錯。更糟的是，如果一些重要數據，比如說訂單的某一項值爲Null了，那麼大家知道，任何值與Null相操作(比如加減乘除)，結果都是Null，導致的結果就是訂單的總金額也爲Null。
你可以運行下面的代碼嘗試一下：
Select Null + 5 As Result
你可能會說，就算我將字段設置成Not Null，但是它依然可以接受空字符串，這樣一來在程序中還是要進行空值處理。請別忘了，數據庫還賦予你一個強力武器，就是 Check 約束，當你需要確保一個字段既不可以爲Null，又不可以爲空的時候，可以這麼寫：
ColumnName Varchar(50) Not Null Constraint ck_ColumnName Check(Len(ColumnName) > 0)
所以，合理的思維方式應該是這樣的：默認這個字段是 Not Null的，然後判斷這個字段是不是非爲Null不可，如果不是這樣，OK，這個字段是Not Null的，進行下一個字段。
一個建表的範例腳本
個人空間的表的建立，其中的文章表是這樣寫的：
Create Table Article
(
Id Int Identity(1,1) Not Null,
Title Varchar(50) Not Null Constraint uq_ArticleTitle Unique,
Keywords Varchar(50) Not Null,
Abstract Varchar(500) Not Null,
Author Varchar(50) Not Null Default '張子陽',
Type TinyInt Not Null Default 0 Constraint ck_ArticleType Check(Type in (0,1,2)), -- 0,原創；1,編譯；2,翻譯
IsOnIndex Bit Not Null Default 1, -- 是否顯示在首頁
Content Text Not Null,
SourceCode Varchar(100) Null, -- 程序源碼的下載路徑
Source Varchar(50) Not Null Default 'TraceFact', -- 文章出處
SrcUrl Varchar(150) Null, -- 文章出處的URL
PostDate DateTime Not Null Default GetDate(),
ViewCount Int Not Null Default 0,
ClassId Int Not Null -- 外鍵包含的字段，文章類別
Constraint pk_Article Primary Key(Id) -- 建立主鍵
)
可以看到，在這裏我使用了 Check 約束，以確保文章類型只能爲 0,1,2。這裏，我想說的是Check 約束的命名規則：儘管Check約束是針對字段的，但在同一數據庫中，卻不能有同名的Check約束。所以，建議使用 ck_ + 表名 + 字段名 來命名它，比如這個範例腳本中的 ck_ArticleType。
除此以外，我還使用了Unique約束，以確保文章標題的唯一性。由於這是我的博客文章表，不應該出現重複的題目，這樣可以避免在使用 Insert 語句時插入重複值。類似於Check約束，這裏的命名規則是：uq_ + 表名 + 字段名。
主鍵的命名
按照SQL Server 的默認規範(使用企業管理器創建主鍵時默認產生的主鍵名)，主鍵的命名爲 pk_TableName。主鍵是針對一個表的，而不是針對一個字段的，大家有時候在企業管理器中會見到一個表的兩個字段前面都會有鑰匙的圖標(比如SQL Server 2000自帶的NorthWind範例數據庫的EmployeeTerritories表)，就會誤以爲主鍵是針對字段的，即是說一個表上有兩個主鍵，其實錯了，只有一個主鍵，但包含了兩個字段，這就是常說的複合主鍵。爲了有個更生動的認識，看下建立複合主鍵的SQL語句，以上面說到的多對多連接表StudentCourse爲例：
Alter Table StudentCourse
Add Constraint pk_StudentCourse Primary key(StudentId, CourseId)
可見，對於主鍵pk_StudentCourse，包含了兩個字段StudentId 和 CourseId。
外鍵的命名
外鍵的命名爲 fk_外鍵所在的表名_外鍵引用的表名。因爲外鍵所在的表爲從表，所以上式可以寫爲 fk_從表名_主表名。
外鍵包含的字段的命名，外鍵包含的字段和外鍵是完全不同的概念。外鍵包含字段的命名，建議爲：外鍵所在的表名 + Id。
考慮這樣一個關係，表Hotel，字段Id, Name, CityId。表City,字段Id,Name。因爲一個城市可能有好多家酒店，所以是一個一對多的關係，City是主表(1方)，Hotel是從表(多方)。在Hotel表中，CityId是做爲外鍵使用。
在實現外鍵的時候我們可以這樣寫：
Alter Table HotelInfo
Add Constraint fk_HotelInfo_City Foreign Key (CityID) References City(ID)
On Delete No Action On update No Action
很明顯，fk_HotelInfo_City是外鍵的名字，CityId是外鍵包含的字段的名字。
NOTE：在創建數據庫表的時候，一般需要寫成三個SQL腳本文件。第一個文件僅包含所有的創建表的SQL語句，即Create Table 語句。第二個文件包含刪除關係和表的語句，其中，所有刪除關係的語句，即Drop Constraint 語句集中在這個文件的上半部分，所有刪除表的語句，Drop Table語句，集中在這個文件的下半部分。第三個文件包含建立表之間關係的語句。這種做法會在你移植數據庫的時候產生較大的便利，原因我就不解釋了，您一試便知。
而對於多對多關係中解析表的外鍵包含的字段，順理往下推，我們可以這樣寫(再次回到學生選課的多對多例子中)：
建立解析表StudentCourse與Student表的外鍵關係：
Alter Table StudentCourse
Add Constraint fk_StudentCourse_Student Foreign Key (StudentId) References Student (Id)
On Delete No Action On Update No Action
建立解析表StudentCourse與Course 表的外鍵關係:
Alter Table StudentCourse
Add Constraint fk_StudentCourse_Course Foreign Key (CourseId) References Course(Id)
On Delete No Action On Update No Action
觸發器的命名
由三部分構成：
- 前綴(tr),描述了數據庫對象的類型。
- 基本部分，描述觸發器所加的表。
- 後綴(_I、_U、_D)，顯示了修改語句(Insert, Update及Delete)
存儲過程的命名
大家知道，系統存儲過程的前綴是 sp_，爲了避免將用戶存儲過程與系統存儲過程混淆，這裏我推薦大家使用 pr 作爲自己定義的存儲過程的命名。
同時，命名的規則是：採用自解釋型的命名，比如：prGetItemById。
這裏，有個有意思的地方值得深思。我們按上面規則命名存儲過程的時候，可以用兩種方式：
- 動詞放前面，名詞放後面。
- 名詞放前面，動詞放後面。
我個人推薦使用方式2，現在說說原因：
以NorthWind 爲例，假如對於 Employees 表你有4個存儲過程，分別命名爲：prEmployeeInsert、prEmployeeUpdate、prEmployeeDelById、prEmployeeGetById
同時對於 Products 表你有類似的4個存儲過程，分別命名爲：prProductInsert、prProductUpdate、prProductDelById、prProductGetById
這時，你用企業管理器查看時，會發現存儲過程像下面這樣整整齊齊的排列：
prEmployeeDelById
prEmployeeGetById
prEmployeeInsert
prEmployeeUpdate
prProductDelById
prProductGetById
prProductInsert
prProductUpdate
很容易就會發現，當你的存儲過程越多時，這種命名方法的優勢就越明顯。
存儲過程中參數的命名
存儲過程中的入口參數，我建議與其對應的字段名相同，這裏，假設要寫一個更新Northwind數據庫Employees表的存儲過程(做了簡化)，可以這麼寫：
Create Procedure prEmployeeUpdateById
@EmployeeId Int,
@LastName NVarchar(20),
@FirstName NVarchar(10)
As
Update Employees Set
LastName = @LastName,
FirstName = @FirstName
Where
EmployeeId = @EmployeeId
If @@error <> 0 or @@RowCount = 0
Raiserror 16001 ‘更新用戶失敗’
參考
2 數據庫命名原則
如果數據庫採用文件系統，而不是裸設備，約定下列命名規則：
1)數據文件以表空間名爲開始，以.dbf爲結尾，全部採用小寫英文字母加數字命名。如該表空間有多個數據文件，則從第2個數據文件開始，在表空間名後加_。
例：對system表空間的數據文件：system.dbf,system_2.dbf
2)對oracle數據庫的控制文件，用control.ctl來表示。如control01.ctl,control02.ctl。
3)對oracle數據庫的日誌文件，在線日誌文件用redo<組名><文件序列名>.dbf來表示。其中組名和文件序列名均用2位數字來表示。如第一組的兩個文件表示位redo0101.dbf和redo0102.dbf。歸檔日誌用arch_%t_%s.arc來表示。其中%t和%s均爲oracle約定的變量。
數據庫系統表空間包括system表空間，臨時表空間，回滾段的表空間。約定下列命名規則：
1)system表空間由數據庫直接限定，不能進行修改。
2)臨時表空間用temp來表示。如果有多個臨時表空間，從第2個臨時表空間開始，在temp後面加來表示。
3)回滾段表空間用undotbs來表示。如果有多個回滾段表空間，從第2個回滾段表空間開始，在undotbs後面加來表示。
數據庫的用戶表空間用ts_<表空間名>來表示。其中，表空間名分爲：
1)數據空間：對於用戶的缺省表空間，用default來表示。對於其他的表空間，根據存放在表空間上的表的類別來表示。如放代碼的表，用code來表示。放客戶資料的表，用customer來表示。儘量用一個表空間來存放該類的表。如果某表特別大，可考慮單獨使用一個表空間。
2)索引空間：在相應的數據表空間的名字前加ind_。如對用戶缺省表空間的索引空間，用ts_ind_default來表示。對代碼表的索引表空間，用ts_ind_code來表示。
數據庫表的命名採用如下規則：
1)表名用T_開頭，表名長度不能超過30個字符，表名中含有單詞全部採用單數形式，單詞要大寫。
2)多個單詞間用下劃線（_）進行連接。若庫中有多個系統，表名採用系統名稱+單詞或多個單詞，系統名是開發系統的縮寫，如VNET。
3）表中含有的單詞建議用完整的單詞。如果導致表名長度超過30個字符，則從最後一個單詞開始，依次向前採用該單詞的縮寫。（如果沒有約定的縮寫，則採用該單詞前4個字母來表示）。
數據庫表的字段命名採用如下規則：
1）數據庫字段名全部採用小寫英文單詞，單詞之間用”_”隔開。字段長度不能超過30個字符。
2）如果該字段是代碼，則在單詞後加_id。
3）如果該字段表示的是時間，則使用_time爲後綴。
數據庫視圖的命名採用如下規則：
1）視圖名用V_開頭，視圖名長度不能超過30個字符。視圖名用大寫的英文單詞來表示。
2）視圖由幾個表產生就用下劃線（_）連接幾個表的名，如果表過多可以將表名適當簡化，但一定要列出所有表名。
數據庫序列的命名採用如下規則：
序列名用seq_開頭，後面跟使用該序列的字段名。如果有幾個字段用同一個序列，用下劃線（_）連接幾個字段的名稱。如果不同表中相同的字段名需要使用不同的序列，則在字段名後加表的特徵，用下劃線（_）連接。序列名長度不能超過30個字符。序列名用小寫的英文單詞來表示。
存儲過程的命名採用如下規則：
存儲過程名用Pr_開頭，存儲過程名長度不能超過30個字符。存儲過程名用小寫的英文單詞來表示。
函數的命名採用如下規則：
函數名用Fu_開頭，函數名長度不能超過30個字符。函數名用小寫的英文單詞來表示。
觸發器的命名採用如下規則：
觸發器名用Tr_開頭，觸發器名長度不能超過30個字符。觸發器名用小寫的英文單詞來表示。
主鍵的命名採用如下規則：
主鍵名用pk_開頭，後面跟該主鍵所在的表名。主鍵名長度不能超過30個字符。如果過長，可對錶名進行縮寫。縮寫規則同表名的縮寫規則。主鍵名用小寫的英文單詞來表示。
外鍵的命名採用如下規則：
外鍵名用fk_開頭，後面跟該外鍵所在的表名和對應的主表名（不含t_）。子表名和父表名自己用下劃線（_）分隔。外鍵名長度不能超過30個字符。如果過長，可對錶名進行縮寫。縮寫規則同表名的縮寫規則。外鍵名用小寫的英文單詞來表示。
索引的命名採用如下規則：
1）索引名用小寫的英文字母和數字表示。索引名的長度不能超過30個字符。
2）主鍵對應的索引和主鍵同名。
3）每類索引都用_結束。
4）唯一性索引用uni_開頭，後面跟表名。一般性索引用ind_開頭，後面跟表名。
5）如果索引長度過長，可對錶名進行縮寫。縮寫規則同表名的縮寫規則。
