資料庫命名規范
一份設計合理的資料庫，對程序開發可以達到事半功倍的效果，對於後期維護、二次開發的重要性更是不言而喻。
數據設計、實現過程中的注意事件（個人觀點）：
1.命名規范：
1）表：模塊前綴+英文單詞，如 BBS_UserInfo；
2）欄位：表前綴+英文單詞，如 U_Name；
2.三大範式：
盡量滿足資料庫設計三大範式。
第一範式（1NF）是指資料庫表的每一列都是不可分割的基本數據項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重復的屬性。
第二範式（2NF）：要求資料庫表中的每個實例或行必須可以被惟一地區分，資料庫表中不存在非關鍵欄位對任一候選關鍵欄位的部分函數依賴（部分函數依賴指的是存在組合關鍵字中的某些欄位決定非關鍵欄位的情況），也即所有非關鍵欄位都完全依賴於任意一組候選關鍵字。
第三範式（3NF）：要求一個資料庫表中不包含已在其它表中已包含的非主關鍵字信息，在第二範式的基礎上，數據表中如果不存在非關鍵欄位對任一候選關鍵欄位的傳遞函數依賴則符合第三範式。
3.數據結構：
建立必要的主外鍵關系、建立好多表查詢聯合查詢、復雜條件查詢的儲存過程等等。
4.保留資料庫設計文檔（這點對於二次開發尤為重要）。
--------------友情分割線（以下為收藏資料，已忘記原出處）--------------
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。產品明細表中的產品名稱可用ProctName表示。（推薦一般用完整的英文單詞）。
系統中所有屬於內碼欄位（僅用於標示唯一性和程序內部用到的標示性欄位），名稱取為：「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]
@ProctionType 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表中用戶自定義的錯誤消息即可。
------------------------------------------
『貳』 AD如何設計資料庫並且命名
資料庫設計過程中命名規范很是重要，命名規范合理的設計能夠省去開發人員很多時間去區別資料庫實體。 資料庫物理設計包括：表設計，視圖設計，存儲過程設計，用戶自定義函數設計等等。
1、表設計命名規范：表使用t開頭最好能將表根據屬性分類並作好編號。 如：編碼表可寫為tBM001Somethingt為表開頭，BM為業務類型，001為該類別中的第幾個表something是表的名稱注釋。
『叄』 「oracle」的命名規范是什麼
標准命名規則要滿足如下要求：以字元開頭，30個字元以內，只稿圓能包含A-Z,a-z,0-9,_,$,#，不能和同一個用戶下的其他對象重名，不能是oracle伺服器的保留字
還有一類是非標准命名，可以使用任何字元，包括中文，oracle中的保留字，空格等等都是可以的，但是需要將對象名用雙引號引起來。
『肆』 MySQL表欄位的命名規范是什麼
可以用駝峰法。
『伍』 數據表命名規則中只能使用
數據表命名規則中只能使用以下字元：
1. 字母（A~Z、a~z）
2. 數字（0~9）
3. 下劃線（_）運灶
在命名數據晌悄稿表時，應該遵循以下規則：
1. 數據表名應該能夠准確描述其中存儲的數據類型，名稱應該盡可能簡潔、准確。
2. 數據表名應該以字母或下劃線開頭，不推薦使用數字開頭。
3. 數據表名不應該超過64個字元，以避免在某些資料庫中出現問題。
4. 數據表名中應該避免使用空格和特殊字元，以免出現不可預測錯誤。
5. 數據表名應該遵循一定的命名規范，例如採用下劃線分隔單詞或使用駝峰命名法等。
如果您在命名數據表時遵循了宴孝以上規則，但仍然無法正常工作，可以檢查資料庫的設置和許可權是否存在問題，或者嘗試重新命名數據表。這些方法可能有助於解決數據表命名問題。
『陸』 資料庫表的名字命名不符合規范，在查詢的時候出現意想不到的錯誤，請問怎麼解決
一：資料庫引擎沒有啟動： 開始->程序->Microsoft SQL Server 2005->SQL Server 2005外圍應用配置器,在打開的界面單擊"服務的連接的外圍應用配置器",在打開的界面中找到Database Engine,單擊"服務",在右側查看是否已啟動,如果沒有啟動可單擊"啟動",並確保"啟動類型"為自動,不要為手動,否則下次開機時又要手動 二：啟動行遠程連接設置沒有打開 1.指向「開始->程序->Microsoft SQL Server 2005->配置工具->SQL Server 外圍應用配置器」 2.在「SQL Server 2005 外圍應用配置器」頁, 單擊「服務和連接的外圍應用配置器」 3.然後單擊展開「資料庫引擎」， 選中「遠程連接」，在右邊選中「本地連接和遠程連接」， 再選擇要使用的協議，( 這個地方應當啟用TCP/IP 和命名管道服務！)單擊「應用」，您會看到下消息： 「直到重新啟動資料庫引擎服務後，對連接設置所做的更改才會生效。」，單擊「確定」按鈕返回 4.展開「資料庫引擎」， 選中「服務」，在右邊單擊「停止」，等到 MSSQLSERVER 服務停止， 然後單擊「啟動」，重新啟動MSSQLSERVER 服務。