1數據庫表及字段命名、設計規范
1.1數據庫表數據庫表的命名規范：
表的前綴應該用系統或模塊的英文名的縮寫（全部大寫或首字母大寫）。如果系統功能簡單，沒有劃分為模塊，則可以以系統英文名稱的縮寫作為前綴，否則以各模塊的英文名稱縮寫作為前綴。例如：如果有一個模塊叫做BBS(縮寫為BBS),那么你的數據庫中的所有對象的名稱都要加上這個前綴：BBS_ + 數據庫對象名稱，BBS_CustomerInfo標示論壇模塊中的客戶信息表
表的名稱必須是易于理解，能表達表的功能的英文單詞或縮寫英文單詞，無論是完整英文單詞還是縮寫英文單詞，單詞首字母必須大寫。如果當前表可用一個英文單詞表示的，請用完整的英文單詞來表示；例如：系統資料中的客戶表的表名可命名為：SYS_Customer。如果當前表需用兩個或兩個以上的單詞來表示時，盡量以完整形式書寫，如太長可采用兩個英文單詞的縮寫形式；例如：系統資料中的客戶物料表可命名為：SYS_CustItem。
表名稱不應該取得太長（一般不超過三個英文單詞）。
在命名表時，用單數形式表示名稱。例如，使用 Employee，而不是 Employees。
對于有主明細的表來說。明細表的名稱為：主表的名稱 + 字符Dts。例如：采購定單的名稱為：PO_Order，則采購定單的明細表為：PO_OrderDts
對于有主明細的表來說，明細表必須包含兩個字段：主表關鍵字、SN，SN字段的類型為int型，目的為與主表關鍵字聯合組成明細表的關鍵字，以及標示明細記錄的先后順序，如1,2,3……。
表必須填寫描述信息
后臺表名盡量與前臺表名相同，后臺獨有的表應以_b作為后綴。如r_gggd_b
1.2表字段
?命名規范 ? ? ??
?數據庫字段的命名必須遵循以下規范：
采用有意義的字段名。字段的名稱必須是易于理解，能表達字段功能的英文單詞或縮寫英文單詞，單詞首字母必須大寫，一般不超過三個英文單詞。例如:人員信息表中的電話號碼可命名為：Telephone或Tel。產品明細表中的產品名稱可用ProductName表示。（推薦一般用完整的英文單詞）。
系統中所有屬于內碼字段（僅用于標示唯一性和程序內部用到的標示性字段），名稱取為：“ID”，采用整型或長整型數，具體根據可能的數據量確定，增加記錄時取最大值加1，該字段通常為主關鍵字。
系統中屬于是業務范圍內的編號的字段，其代表一定的業務信息，比如資料信息和單據的編號，這樣的字段建議命名為：“Code”，其數據類型為varchar，該字段需加唯一索引。
在命名表的列時，不要重復表的名稱；例如，在名為 Employee 的表中避免使用名為 EmployeeLastName 的字段。
不要在列的名稱中包含數據類型。


設計規范
所有字段在設計時，除以下數據類型timestamp、image、datetime、smalldatetime、uniqueidentifier、binary、sql_variant、binary 、varbinary外，必須有默認值。字符型的默認值為一個空字符值串’’；數值型的默認值為數值0；邏輯型的默認值為數值0；
其中：系統中所有邏輯型中數值0表示為“假”；數值1表示為“真”。
?? ?datetime、smalldatetime類型的字段沒有默認值，必須為NULL。
當字段定義為字符串形時建議使用varchar而不用nvarchar。
建議在大多數表中（如報銷單，申請單），應都有以下字段：
字段名說明類型默認值
CreatorID創建者int0
CreatedTime創建時間DatetimeNULL


字段的描述
數據庫中每個字段的描述(Description)如下：
?? ?
盡量遵守第三范式的標準（3NF）。
表內的每一個值只能被表達一次
表內的每一行都應當被唯一的標示
表內不應該存儲依賴于其他鍵的非鍵信息
如果字段事實上是與其它表的關鍵字相關聯而未設計為外鍵引用，需建索引。
如果字段與其它表的字段相關聯，需建索引。
如果字段需做模糊查詢之外的條件查詢，需建索引。
除了主關鍵字允許建立簇索引外，其它字段所建索引必須為非簇索引。
字段必須填寫描述信息
2存貯過程命名及設計規范
2.1命名規范
存貯過程的命名請遵循以下命名規范：USP _ + 系統模塊縮寫（與表前綴類似）+_ + 功能標識 + 代表存貯過程操作的主要表名（不帶前綴）或功能的英文單詞或英文單詞縮寫。
如果一個存貯過程只對一個表進行操作，建議存貯過程的名稱就用存貯過程所操作的表的表名（不帶前綴）。這樣有利于根據表名找到相應的存貯過程。
為了在眾多的存貯過程中能很快的找到并維護存貯過程，我們按存貯過程的作用將系統的存貯過程
進行以下的分類及命名：（以下示例假設存貯過程所在的模塊名為ORG）
作用第一前綴第二前綴名
(功能標識)示例
用于新增的存貯過程USP_ORGAddUSP_ORG_Add_Employee
用于修改的存貯過程USP_ORGUptUSP _ORG_Upt_Employee
用于刪除的存貯過程USP_ORGDelUSP _ORG_Del_Employee
用于單據查詢的存貯過程USP_ORGQryUSP _ORG_Qry_Employee
用于報表統計的存貯過程USP_ORGRptUSP _ORG_Rpt_GetEmployee
用于一些特殊過程處理的存貯過程USP_ORGOthUSP _ORG_Oth_SetSystemMessage
如果系統中的存貯過程只有一級，則遵照以上規則命名，如果存在多級，則需要區分其屬于哪一級，具體為：USP + 所屬的級次 + _ + 后面的部分
例如：
1.USP1_ORG_Add_Subject ? ? ? ?（沒有調用其它存貯過程）
2.USP2_ORG_Upt_Subject ? ? ? ? ?(調用了第1級的存貯過程)
3.USP3_ORG_Qry_Subject ? ? ? ? ?(調用了第2級的存貯過程)
2.2設計規范
在存貯過程中必須說明以下內容：
目的：說明此存貯過程的作用。
作者：首次創建此存貯過程的人的姓名。在此請使用中文全名，不允許使用英文簡稱。
創建日期：創建存貯過程時的日期。
修改記錄：
修改記錄需包含修改順序號、修改者、修改日期、修改原因，修改時不能直接在原來的代碼上修改，也不能刪除原來的代碼，只能先將原來的代碼注釋掉，再重新增加正確的代碼。修改順序號的形式為：log1，log2，log3。。。，根據修改次數順序增加，同時在注釋掉的原來的代碼塊和新增的正確代碼塊前后注明修改順序號。
對存貯過程各參數及變量的中文注解。
示例如下：
/*
目的：根據部門與物料和會計區間查詢生產現場領料匯總報表
作者：李奇
創建日期：2002-12-11
*/
/*
修改順序號：log1
修改者：劉敏
修改日期：2002.12.22
修改原因：（具體原因詳細描述）
*/
CREATE PROCEDURE [dbo].[USP_GetLMSSum]
@ProductionType int=1, ? ?--生產類型（1-自制；0-委外加工）
@DeptID int=0, ? ? --生產部門
@ItemID int=0, ? ? --物料
@StartDate datetime='2002-11-26',--會計區間開始日期
@EndDate datetime='2002-12-25'--會計區間截止日期
AS
/*
log1 old
--自制領料
INSERT INTO #LMSDts
SELECT dbo.iStockBill.DeptID, dbo.fDept.DeptName,?
?? ? ?dbo.mLMS.ItemID AS ItemInterID, dbo.fItem.ItemID, dbo.fItem.ItemName,?
?? ? ?ISNULL(dbo.fItem.Model, N'') AS Model, ISNULL(dbo.fUnit.UnitName, N'')?
?? ? ?AS UnitName, dbo.mLMS.Qty, dbo.mLMS.TransType, dbo.mWO.OrderType,?
?? ? ?dbo.mLMS.CreateTime
end log1 old?
*/
--log1 new
--自制領料
INSERT INTO #LMSDts
SELECT dbo.iStockBill.DeptID, dbo.fDept.DeptName,?
?? ? ?dbo.mLMS.ItemID AS ItemInterID, dbo.fItem.ItemID, dbo.fItem.ItemName,?
?? ? ?ISNULL(dbo.fItem.Model, N'') AS Model, ISNULL(dbo.fUnit.UnitName, N'')?
?? ? ?AS UnitName, dbo.mLMS.Qty, dbo.mLMS.TransType, dbo.mWO.OrderType,?
?? ? ?dbo.mLMS.CreateTime
--end log1 new


3 視圖命名規范
3.1命名規范
視圖的命名請遵循以下命名規范：UV _ + 系統模塊縮寫（與表前綴類似）+_ + 功能標識 + 代表視圖查詢的主要表名（不帶前綴）或功能的英文單詞或英文單詞縮寫。
如果一個視圖只對一個表進行查詢，建議視圖的名稱就用視圖所查詢的表的表名（不帶前綴）。這樣有利于根據表名找到相應的視圖。
為了在眾多的視圖中能很快的找到并維護視圖，我們按其作用將系統的視圖
進行以下的分類及命名：（以下示例假設視圖所在的模塊名為ORG）
作用第一前綴第二前綴名
(功能標識)示例
用于單據查詢的視圖UV_ORGQryUV_ORG_Qry_Employee
用于報表統計的視圖UV_ORGRptUV_ORG_Rpt_GetEmployee
用于一些特殊過程處理的視圖UV_ORGOthUV_ORG_Oth_SetSystemMessage
如果系統中的視圖只有一級，則遵照以上規則命名，如果存在多級，則需要區分其屬于哪一級，具體為：UV + 所屬的級次 + _ + 后面的部分
例如：
UV1_ORG_Add_Subject ? ? ? ?（沒有調用其它視圖）
UV2_ORG_Upt_Subject ? ? ? ? ?(調用了第1級的視圖)
UV3_ORG_Qry_Subject ? ? ? ? ?(調用了第2級的視圖)
3.2 設計規范
在視圖中必須說明以下內容：
目的：說明此視圖的作用。
創建者：首次創建此視圖的人的姓名。在此請使用中文全名，不允許使用英文簡稱。
修改者、修改日期、修改原因：如果有人對此視圖進行了修改，則必須在此視圖的前面加注修改者姓名、修改日期及修改原因。
對視圖各參數及變量的中文注解。
示例如下：
/*
目的：查詢本月所要培訓的科目
創建：加菲貓
時間：2001-3-3
修改者：Dyan ? ?修改日期：2002-12-11 ? ? ?
修改原因及內容：學員不需要培訓，將不需要培訓的課程去掉。
修改者：周明 ? ?修改日期：2002-4-2 ? ? ?
修改原因及內容：增加一門新課程
*/
CREATE VIEW dbo.USP_AddSubject
AS
SELECT SubjectIId AS 課程編號 ? ?
FROM dbo.ZfLocaleDecide
3.3 存儲過程和事務處理
如果事務處理在存儲過程返回時的嵌套層次與執行時的層次不同，SQL Server會顯示信息提示事務處理嵌套失控。因為存儲過程并不異常終止該批處理，在執行和確認隨后的語句時，過程內的rollback tran 會導致數據完整性損失。
在編寫存儲過程時，應遵守以下原則：
1．過程對@@trancount應無凈改變。
2．僅當存儲過程發出begin tran語句時，才發出rollback tran。
3.4 其他注意事項
存儲過程應該堅實可靠的，因為它們是駐留在服務器中，被頻繁使用的。應仔細檢查參數的有效性，并在有問題時返回出錯信息。應確保參數的數據類型和被比較的欄的數據類型匹配，從而避免數據類型匹配錯誤。在每個SQL語句之后要檢查@@error。
4觸發器編碼規范
4.1命名規范
觸發器名為相應的表名加上后綴
Insert觸發器加'_i'，Delete觸發器加'_d'，Update觸發器加'_u'，如：r_bch_i，r_bch_d，r_bch_u。
4.2 設計規范
在觸發器中必須說明以下內容：
目的：說明此觸發器的作用。
創建者：首次創建人的姓名。在此請使用中文全名，不允許使用英文簡稱。
修改者、修改日期、修改原因：如果有人對此視圖進行了修改，則必須在此視圖的前面加注修改者姓名、修改日期及修改原因。
對其中各參數及變量的中文注解。
4.3范例
下面通過一個例子，說明觸發器編程中應遵守的規范：
/* delete related r_a according to deleted table */
CREATE TRIGGER r_a_d ON r_a
?? ? ?FOR DELETE
AS
IF @@ROWCOUNT = 0 -no rows deleted
?? ? ? ? ?RETURN
/* delete r_b table related to deleted table */
DELETE r_b
?? ? ? ? ?FROM r_b b, deleted d
?? ? ? ? ?WHERE b.id=d.id
IF @@ERROR != 0
?? ?BEGIN
?? ? ? ? ?RAISERROR("Error occurred deleting related records", 16, 1)?
?? ? ? ? ?ROLLBACK TRAN
END
RETURN
作以下幾點說明：
1．檢查是否有行被修改。注意：不論數據是否被修改，觸發器都會引發，執行情況取決于T-SQL語句的執行，而和任何潛在的where子句是否執行無關。
2．因為被刪除行在該表中不再可用，所以應在被刪除的表中查看。
3．檢查T-SQL語句的返回代碼，以捕獲任何出錯條件。
4.4 事務過程中的觸發器
1．觸發器內的rollback將所有工作返回至最外層的begin tran，完成觸發器內的處理并異常終止當前的批處理。
2．不可以從觸發器內部返回至某個已命名的事務過程，這將產生運行錯誤，掛起所有工作并終止批處理。
5 SQL語言編碼規范
5.1所有關鍵字必須大寫。
如：INSERT、UPDATE、DELETE、SELECT及其子句。
IF……ELSE、CASE、DECLARE等。
所有函數及其參數中除用戶變量以外的部分必須大寫。
?在定義變量時用到的數據類型必須小寫。
?所有關鍵字必須大寫
5.2注釋
注釋可以包含在批處理中。在觸發器、存儲過程中包含描述性注釋將大大增加文本的可讀性和可維護性。本規范建議：
1、注釋以英文為主。
?? ?實際應用中，發現以中文注釋的SQL語句版本在英文環境中不可用。為避免后續版本執行過程中發生某些異常錯誤，建議使用英文注釋。
2、注釋盡可能詳細、全面。
創建每一數據對象前，應具體描述該對象的功能和用途。
傳入參數的含義應該有所說明。如果取值范圍確定，也應該一并說明。取值有特定含義的變量（如boolean類型變量），應給出每個值的含義。
3、注釋語法包含兩種情況：單行注釋、多行注釋
單行注釋：注釋前有兩個連字符（--），最后以行尾序列（CR-LF）結束。一般，對變量、條件子句可以采用該類注釋。
多行注釋：符號/*和*/之間的內容為注釋內容。對某項完整的操作建議使用該類注釋。
4、注釋簡潔，同時應描述清晰。
5函數注釋：
編寫函數文本--如觸發器、存儲過程以及其他數據對象--時，必須為每個函數增加適當注釋。該注釋以多行注釋為主，主要結構如下：
/************************************************************************
*name ? ? ? ?: ? ? ? ? ? ? ? --函數名
*function ? ?: ? ? ? ? ? ? ? --函數功能
*input ? ? ? : ? ? ? ? ? ? ? --輸入參數
*output ? ? ?: ? ? ? ? ? ? ? --輸出參數
*author ? ? ?: ? ? ? ? ? ? ? --作者
*CreateDate ?: ? ? ? ? ? ? --創建時間
*UpdateDate ?: ? ? ? ? ? ? ? --函數更改信息（包括作者、時間、更改內容等）
*************************************************************************/
CREATE PROCEDURE sp_xxx
…


5.3條件執行語句if…else
條件語句塊（statenemt block，以 begin…end為邊界）僅在if子句的條件為真時才被執行。
為提高代碼的可讀性，建議嵌套不多于5層。還有，當嵌套層次太多時，應該考慮是否可以使用case語句。
5.4重復執行while和跳轉語句goto
需要多次執行的語句，可以使用while結構。其中，控制while循環的條件在任何處理開始之前需要先執行一次。循環體中的保留字break無條件的退出while循環，然后繼續處理后續語句；保留字continue重新計算while條件，如果條件為真，則從循環開始處重新執行各語句。
使用跳轉語句goto和標簽label也可以方便地實現循環和其他更靈活的操作。SQL SERVER僅具有單通道語法分析器，因此不能解析對尚未創建的對象所做的前向參考。換言之，跳轉到某標簽的后續語句應該是可執行的（如不存在可能尚未創建的數據對象）。
5.5書寫格式
數據庫服務器端的觸發器和存儲過程是一類特殊的文本，為方便開發和維護，提高代碼的易讀性和可維護性。規范建議按照分級縮進格式編寫該文本。
順序執行的各命令位于同一級；條件語句塊（statenemt block，以 begin…end為邊界）位于下一級，類推。
SQL語句是該文本的主體。為適應某些教復雜的用戶需求，SQL語句可能比較龐大。為方便閱讀和維護，規范建議按照SQL語句中系統保留字的關鍵程度再劃分為三級。具體分級請參照下表。其中，非系統保留字（如字段名、數據表名、標點符號）相對本級保留字再縮進一級。多個連續的非保留字可以分行書寫，也可以寫在同一行。當WHERE包含的條件子句教復雜時，應該每行只寫一個條件分句，并為重要的條件字句填寫單行注釋。
在保證基本縮進格式的前提下，可以通過對齊某些重要關鍵字（如條件關鍵字AND、OR，符號 = 、 <> 等）來進一步提高文本的易讀性和可維護性。
相鄰兩級的縮進量為10個空格。這也是ISQL編輯器默認的文本縮進量。另外，在ISQL編輯器中，一個TAB鍵也相當于10個空格。


6數據對象的國際化
6.1關于數據對象的命名
數據對象和變量的命名一律采用英文字符。禁止使用中文命名。其他命名注意事項和規范請參考2命名規則。
6.2關于RAISERROR
SQL SERVER 系統的RAISERROR命令能夠把某個出錯情況返回給調用過程，這對說明調用過程的執行情況很有必要；同時可以部分避免客戶端的冗余操作。另外，結合系統存儲過程sp_addmessage和sp_dropmessage可以方便實現數據對象在SQL SERVER端的國際化。
SQL SERVER的MASTER數據庫中有錯誤信息數據表sysmessages，專門用于存儲系統和用戶的錯誤提示及相關信息（如錯誤ID號、錯誤等級、狀態）。用戶可以調用sp_addmessage和sp_dropmessage預先將各類錯誤信息記入該數據表。其中，不同的錯誤信息用錯誤ID號區分。在編寫存儲過程代碼時，調用RAISERROR函數從錯誤信息表sysmessages中引用相關錯誤ID號的錯誤信息。
由于0~50000的值是保留為 SQL SERVER使用的，所以用戶自定義錯誤信息的錯誤ID號必須大于50000。
RAISERROR的語法如下：
RAISERROR ({msg_id | msg_str}, severity, state )
?? ?本規范建議存儲過程以RAISERROR和RETURN返回。
舉例如下：
l第一步：生成該錯誤信息
/*insert a error message into the master..sysmessages*/
sp_addMessage 50001 ,16 ,'Can"t update the primary key from table %s'
l第二步：執行存儲過程sp_xxx，異常返回時引用上述錯誤信息
CREATE PROCEDURE sp_xxx
BEGIN
…
RAISERROR(50001 ,16 ,1 ,'r_a') ? -- Can"t update the primary key from table r_a
ROLLBACK TRAN
RETURN(1)
END
l第三步：在DELPHI調用中，通過EDBEngineError捕捉該錯誤
??try
?? ?sp_test.execProc ;
??except
??on e :EDBEngineError
?? ?if e.errors[1].errorcode = 13059 then
?? ? /*hint 'Can"t update the primary key from table r_a'*/
?? ? showMessage(e.errors[1].message) ? ?
??end ;
l第四步：當不再使用該錯誤信息時，應該從錯誤信息表中刪除相應數據
sp_dropMessage 50001
l第五步：錯誤提示信息國際化
用相應語言替換master..sysmessages表中用戶自定義的錯誤消息即可。 與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的数据库表及字段命名、设计规范的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。