1. 資料庫的命名
資料庫約定
全英文，全稱，單數（完全杜絕拼音，更不能使用拼音的首個字母）；
每個單詞的首字母大寫；
單詞之間直接鏈接不要加任何字元。
數據表的名字，使用全小寫資料庫名加下劃線加表名
資料庫名：Sample；表名：Proct；則在資料庫中表名為：sample_Proct
存儲過程的名字，全小寫資料庫名加下劃線加表名加下劃線加操作名
資料庫名：Sample；表名：Proct；操作：Create；則在資料庫中存儲過程名為：sample_Proct_Create
如果有些操作是針對某個欄位或某幾個欄位的，需要寫詳細一些
更新產品名：sample_Proct_UpdateProctName
更新價格：sample_Proct_UpdatePrice
下面給出一些常用的操作英文，增刪改查
Create，新建
Update，更新
Delete，刪除
GetList，查
GetListByName，根據名字來查
變數名，不需要加前綴，不要加資料庫名，不要加表名，直接寫。
注釋，使用.net開發環境中的三個分號模式，每次修改，必須註明如下信息：
作者
時間
內容
modify by kon,20080719,add parameter
rem by kon,20080719,change database,from sample to real
source safe
使用source safe保存資料庫腳本
以腳本方式分別保存每個表和每個存儲過程
2. acess資料庫 表的命名規則
ACCESS開發的命名規則
資料庫涉及字元規則
採用26個英文字母（區分大小寫）和0 －9這十個自然數，加上下劃線_組成，共63個字元。不能出現其他字元（注釋除外）。
資料庫對象命名規則
資料庫對象包括表、視圖（查詢）、存儲過程（參數查詢）、函數、約束。對象名字由前綴和實際名字組成，長度不超過30。前綴：使用小寫字母。
例如：
表 tb
視圖 vi
存儲過程 sp
函數 fn
實際名字
實際名字盡量描述實體的內容，由單詞或單片語合，每個單詞的首字母大寫，其他字母小寫，不以數字和_開頭。
例如：
表 User_Info
視圖 UserList
存儲過程 UserDelete
因此，合法的對象名字類似如下。
表 tbUser_Info、tbMessage_Detail
視圖 vi_MessageList
存儲過程 sp_MessageAdd
資料庫表命名規則
欄位由前綴和實際名字組成。實際名字中首單詞一個系統盡量採取同一單詞。
前綴：使用小寫字母tb，表示表。
例如：tbMember
tbMember_Info
tbForum_Board
tbForum_Thread1
欄位命名規則
數字、字元、日期/時間、lob(大對象)、雜項，欄位由表的簡稱、下劃線，實際名字加後綴組成。
後綴：使用小寫字母，代表該欄位的屬性。
例如: User_Idint
User_Namestr
User_RegDatedtm
視圖命名規則
欄位由前綴和實際名字組成，中間用下劃線連接。
前綴：使用小寫字母vi，表示視圖。
例如：vi_User
vi_UserInfo
存儲過程命名規則
欄位由前綴和實際名字組成，中間用下劃線連接。
前綴：使用小寫字母sp，表示存儲過程。
例如：sp_User
資料庫設計文檔規則
所有資料庫設計要寫成文檔，文檔以模塊化形式表達。大致格式如下：
'-------------------------------------------
' 表名： tbUser_Info
' 建立人：UAM_Richard
' 日期： 2004-12-17
' 版本： 1.0
' 描述： 保存用戶資料
' 具體內容：
' UserId int，自動增量 用戶代碼
' UserName char(12) 用戶名字
' ......
'--------------------------------------------
sql語句規則
所有sql關鍵詞全部大寫，比如Select,Update,FROM,ORDER,BY等。
3. sql server的對象命名規則是什麼
自己搜索一下就是了，我給你一段：
為了提供完善的資料庫管理機制，SQL Server 設計了嚴格的命名規則。在創建或引用資料庫實體，如表、索引、約束等時，必須遵守SQL Server 的命名規則，否則有可能發生一些難以預料和檢查的錯誤。
本文將講述：標識符的分類和格式規定；資料庫對象的命名規定與使用原則。希望對您會有所幫助。
標識符分類
SQL Server的所有對象，包括伺服器、資料庫以及資料庫對象，如表、視圖、列、索引、觸發器、存儲過程、規則、默認值和約束等都可以有一個標識符。對絕大多數對象來說，標識符是必不可少的，但對某些對象如約束來說，是否規定標識符是可選的。對象的標識符一般在創建對象時定義，作為引用對象的工具使用。
例如下面的SQL語句：
Create table student
(
id int primary key,
name varchar(20)
)
這個例子創建了一個表格，表格的名字是一個標識符：student；表格中定義了兩列，列的名字分別是id,name,他們都是合法的標識符。這個例子還定義另外一個未命名的主鍵約束。
SQL Server一共定義了兩種類型的標識符：規則標識符（Regular identifier）和界定標識符(Delimited identifier)。
規則標識符
規則標識符嚴格遵守標識符有關格式的規定。所以在T-SQL語句中凡是規則標識符都不必使用界定符，如[]和『』，來進行界定。
如上述例子中使用的表名student 就是一個規則標識符，在student上不必添加界定符。
界定標識符
界定標識符是那些使用了如[]和『』等界定符號來進行位置限定的標識符，使用了界定標識符，既可以遵守標識符命名規則，也可以不遵守標識符命名規則。
Select * from [student] 是要從student 表格中查詢出所有的數據與
Select * from student 等效。
為什麼呢？因為在「[]」中的標識符遵守標識符命名規則，「[]」被忽略不計。
但如果是不遵守標識符命名規則的標識符，那麼在T-SQL語句中必須使用界定符號加以限定，如：
Select * from [my table]
Where [order]=10
在這個例子中，必須使用界定標識符，因為在from子句中的標識符my talbe中含有空格，而where子句中的標識符order 是系統保留字(在查詢分析器里「order」變藍色)。這兩個標識符都不遵守標識符命名規則，必須使用界定符，否則無法通過代碼編譯。
標識符格式
標識符格式的規定，其具體內容如下：
標識符的首字母必須是以下兩種情況之一：
所有在統一碼(Unicode)2.0標准規定的字元，包括26個英文字母a-z和A-Z，以及其他一些語言字元，如漢字。例如可以給一個表格命名為「學生基本情況」。下劃線「-」、「@」或「#」。
標識符首字母後的字元可以是：
所有在統一碼(Unicode)2.0標准規定的字元，包括26個英文字母a-z和A-Z，以及其他一些語言字元，如漢字。下劃線「-」、「@」、「$」或「#」。
0,1,2,3,4,5,6,7,8,9。
標識符不允許是T-SQL的保留字。
由於T-SQL不區分大小寫，所以無論是保留字的大寫還是小寫都不允許使用。
標識符內部不允許有空格或特殊字元。
Select * from stu[de]nt –編譯器將返回錯誤信息。因為在標識符stu[de]nt中包含了特殊字元「[」和「]」，所以在編譯上述語句時出錯。
?
以某些特殊符號開頭的標識符在SQL Server系統中具有特定的含義。如「@」開頭的標識符表示這是一個局部變數或是一個函數的參數；以「#」開頭的標識符表示這是一個臨時表或存儲過程；一個以「##」開頭的標識符表示這是一個全局的臨時資料庫對象。T-SQL的全局變數以標志「@@」開頭。為避免同這些全局變數混淆，建議不要使用「@@」作為標識符的開始。
無論是界定標識符還是規則標識符都最多隻能容納128個字元，對於本地的臨時表最多可以有116個字元。
對象命名規則
SQL Server 2000 的資料庫對象名字由1-128個字元組成，不區分大小寫。在一個資料庫中創建了一個資料庫對象後，資料庫對象的全名應該由伺服器名、資料庫名、擁有者名和對象名這四個部分組成，格式如下：
[[[server.][database].][owner_name].]object_name 命名必須都要符合標識符的規定。
在實際引用對象時，可以省略其中某部分的名稱，只留下空白的位置。
實例的命名習慣
在SQL Server 2000中默認實例的名字採用計算機名，實例的名字一般由計算機名字和實例名字兩部分組成。
總之，正確掌握資料庫的命名和引用方式是用好SQL Server 2000的前提，也有助於用戶理解SQL Server 2000中的其他內容。
4. vfp中數據表名稱的命名規則是什麼，欄位名的命名規則又是什麼謝謝。
數據表名的命名規則最好使用文件名不超過8個英文字元（4個中文），自由表的欄位名可以是英文或者下劃線開頭，後面接字母下劃線數字如果是中文版也可以是中文，長度不超過10個英文，中間不能有空格，資料庫表的欄位長度不超過254
5. 資料庫命名規則
對於資料庫的設計中，盡量不用漢字，最好用英文，如果用漢字，有時會產生不必要的麻煩，可能產生插入，刪除等等異常，而且在寫存儲過程或觸發器等等也許會產生錯誤，以下對設計表和欄位的一些規則，可能對提問者用幫助：
1. 檢查各種變化
我在設計資料庫的時候會考慮到哪些數據欄位將來可能會發生變更。比方說，姓氏就是如此（注意是西方人的姓氏，比如女性結婚後從夫姓等）。所以，在建立系統存儲客戶信息時，我傾向於在單獨的一個數據表裡存儲姓氏欄位，而且還附加起始日和終止日等欄位，這樣就可以跟蹤這一數據條目的變化。
2. 採用有意義的欄位名
有一回我參加開發過一個項目，其中有從其他程序員那裡繼承的程序，那個程序員喜歡用屏幕上顯示數據指示用語命名欄位，這也不賴，但不幸的是，她還喜歡用一些奇怪的命名法，其命名採用了匈牙利命名和控制序號的組合形式，比如 cbo1、txt2、txt2_b 等等。
除非你在使用只面向你的縮寫欄位名的系統，否則請盡可能地把欄位描述的清楚些。當然，也別做過頭了，比如 Customer_Shipping_Address_Street_Line_1，雖然很富有說明性，但沒人願意鍵入這么長的名字，具體尺度就在你的把握中。
3. 採用前綴命名
如果多個表裡有好多同一類型的欄位（比如 FirstName），你不妨用特定表的前綴（比如 CusLastName）來幫助你標識欄位。
時效性數據應包括「最近更新日期/時間」欄位。時間標記對查找數據問題的原因、按日期重新處理/重載數據和清除舊數據特別有用。
4. 標准化和數據驅動
數據的標准化不僅方便了自己而且也方便了其他人。比方說，假如你的用戶界面要訪問外部數據源（文件、XML 文檔、其他資料庫等），你不妨把相應的連接和路徑信息存儲在用戶界面支持表裡。還有，如果用戶界面執行工作流之類的任務（發送郵件、列印信箋、修改記錄狀態等），那麼產生工作流的數據也可以存放在資料庫里。預先安排總需要付出努力，但如果這些過程採用數據驅動而非硬編碼的方式，那麼策略變更和維護都會方便得多。事實上，如果過程是數據驅動的，你就可以把相當大的責任推給用戶，由用戶來維護自己的工作流過程。
5. 標准化不能過頭
對那些不熟悉標准化一詞（normalization）的人而言，標准化可以保證表內的欄位都是最基礎的要素，而這一措施有助於消除資料庫中的數據冗餘。標准化有好幾種形式，但 Third Normal Form（3NF）通常被認為在性能、擴展性和數據完整性方面達到了最好平衡。簡單來說，3NF 規定：
* 表內的每一個值都只能被表達一次。
* 表內的每一行都應該被唯一的標識（有唯一鍵）。
* 表內不應該存儲依賴於其他鍵的非鍵信息。
遵守 3NF 標準的資料庫具有以下特點：有一組表專門存放通過鍵連接起來的關聯數據。比方說，某個存放客戶及其有關定單的 3NF 資料庫就可能有兩個表：Customer 和 Order。Order 表不包含定單關聯客戶的任何信息，但表內會存放一個鍵值，該鍵指向 Customer 表裡包含該客戶信息的那一行。
更高層次的標准化也有，但更標準是否就一定更好呢？答案是不一定。事實上，對某些項目來說，甚至就連 3NF 都可能給資料庫引入太高的復雜性。
為了效率的緣故，對表不進行標准化有時也是必要的，這樣的例子很多。曾經有個開發餐飲分析軟體的活就是用非標准化表把查詢時間從平均 40 秒降低到了兩秒左右。雖然我不得不這么做，但我絕不把數據表的非標准化當作當然的設計理念。而具體的操作不過是一種派生。所以如果表出了問題重新產生非標准化的表是完全可能的。
6. Microsoft Visual FoxPro 報表技巧
如果你正在使用 Microsoft Visual FoxPro，你可以用對用戶友好的欄位名來代替編號的名稱：比如用 Customer Name 代替 txtCNaM。這樣，當你用向導程序 [Wizards，台灣人稱為『精靈』] 創建表單和報表時，其名字會讓那些不是程序員的人更容易閱讀。
7. 不活躍或者不採用的指示符
增加一個欄位表示所在記錄是否在業務中不再活躍挺有用的。不管是客戶、員工還是其他什麼人，這樣做都能有助於再運行查詢的時候過濾活躍或者不活躍狀態。同時還消除了新用戶在採用數據時所面臨的一些問題，比如，某些記錄可能不再為他們所用，再刪除的時候可以起到一定的防範作用。
8. 使用角色實體定義屬於某類別的列[欄位]
在需要對屬於特定類別或者具有特定角色的事物做定義時，可以用角色實體來創建特定的時間關聯關系，從而可以實現自我文檔化。
這里的含義不是讓 PERSON 實體帶有 Title 欄位，而是說，為什麼不用 PERSON 實體和 PERSON_TYPE 實體來描述人員呢？比方說，當 John Smith, Engineer 提升為 John Smith, Director 乃至最後爬到 John Smith, CIO 的高位，而所有你要做的不過是改變兩個表 PERSON 和 PERSON_TYPE 之間關系的鍵值，同時增加一個日期/時間欄位來知道變化是何時發生的。這樣，你的 PERSON_TYPE 表就包含了所有 PERSON 的可能類型，比如 Associate、Engineer、Director、CIO 或者 CEO 等。
還有個替代辦法就是改變 PERSON 記錄來反映新頭銜的變化，不過這樣一來在時間上無法跟蹤個人所處位置的具體時間。
• 採用常用實體命名機構數據
組織數據的最簡單辦法就是採用常用名字，比如：PERSON、ORGANIZATION、ADDRESS 和 PHONE 等等。當你把這些常用的一般名字組合起來或者創建特定的相應副實體時，你就得到了自己用的特殊版本。開始的時候採用一般術語的主要原因在於所有的具體用戶都能對抽象事物具體化。
有了這些抽象表示，你就可以在第 2 級標識中採用自己的特殊名稱，比如，PERSON 可能是 Employee、Spouse、Patient、Client、Customer、Vendor 或者 Teacher 等。同樣的，ORGANIZATION 也可能是 MyCompany、MyDepartment、Competitor、Hospital、Warehouse、Government 等。最後 ADDRESS 可以具體為 Site、Location、Home、Work、Client、Vendor、Corporate 和 FieldOffice 等。
採用一般抽象術語來標識「事物」的類別可以讓你在關聯數據以滿足業務要求方面獲得巨大的靈活性，同時這樣做還可以顯著降低數據存儲所需的冗餘量。
• 用戶來自世界各地
在設計用到網路或者具有其他國際特性的資料庫時，一定要記住大多數國家都有不同的欄位格式，比如郵政編碼等，有些國家，比如紐西蘭就沒有郵政編碼一說。
• 數據重復需要採用分立的數據表
如果你發現自己在重復輸入數據，請創建新表和新的關系。
• 每個表中都應該添加的 3 個有用的欄位
* dRecordCreationDate，在 VB 下默認是 Now()，而在 SQL Server 下默認為 GETDATE()
* sRecordCreator，在 SQL Server 下默認為 NOT NULL DEFAULT USER
* nRecordVersion，記錄的版本標記；有助於准確說明記錄中出現 null 數據或者丟失數據的原因
• 對地址和電話採用多個欄位
描述街道地址就短短一行記錄是不夠的。Address_Line1、Address_Line2 和 Address_Line3 可以提供更大的靈活性。還有，電話號碼和郵件地址最好擁有自己的數據表，其間具有自身的類型和標記類別。
過分標准化可要小心，這樣做可能會導致性能上出現問題。雖然地址和電話表分離通常可以達到最佳狀態，但是如果需要經常訪問這類信息，或許在其父表中存放「首選」信息（比如 Customer 等）更為妥當些。非標准化和加速訪問之間的妥協是有一定意義的。
• 使用多個名稱欄位
我覺得很吃驚，許多人在資料庫里就給 name 留一個欄位。我覺得只有剛入門的開發人員才會這么做，但實際上網上這種做法非常普遍。我建議應該把姓氏和名字當作兩個欄位來處理，然後在查詢的時候再把他們組合起來。
我最常用的是在同一表中創建一個計算列[欄位]，通過它可以自動地連接標准化後的欄位，這樣數據變動的時候它也跟著變。不過，這樣做在採用建模軟體時得很機靈才行。總之，採用連接欄位的方式可以有效的隔離用戶應用和開發人員界面。
• 提防大小寫混用的對象名和特殊字元
過去最令我惱火的事情之一就是資料庫里有大小寫混用的對象名，比如 CustomerData。這一問題從 Access 到 Oracle 資料庫都存在。我不喜歡採用這種大小寫混用的對象命名方法，結果還不得不手工修改名字。想想看，這種資料庫/應用程序能混到採用更強大資料庫的那一天嗎？採用全部大寫而且包含下劃符的名字具有更好的可讀性（CUSTOMER_DATA），絕對不要在對象名的字元之間留空格。
• 小心保留詞
要保證你的欄位名沒有和保留詞、資料庫系統或者常用訪問方法沖突，比如，最近我編寫的一個 ODBC 連接程序里有個表，其中就用了 DESC 作為說明欄位名。後果可想而知！DESC 是 DESCENDING 縮寫後的保留詞。表裡的一個 SELECT * 語句倒是能用，但我得到的卻是一大堆毫無用處的信息。
• 保持欄位名和類型的一致性
在命名欄位並為其指定數據類型的時候一定要保證一致性。假如欄位在某個表中叫做「agreement_number」，你就別在另一個表裡把名字改成「ref1」。假如數據類型在一個表裡是整數，那在另一個表裡可就別變成字元型了。記住，你幹完自己的活了，其他人還要用你的資料庫呢。
• 仔細選擇數字類型
在 SQL 中使用 smallint 和 tinyint 類型要特別小心，比如，假如你想看看月銷售總額，你的總額欄位類型是 smallint，那麼，如果總額超過了 $32,767 你就不能進行計算操作了。
• 刪除標記
在表中包含一個「刪除標記」欄位，這樣就可以把行標記為刪除。在關系資料庫里不要單獨刪除某一行；最好採用清除數據程序而且要仔細維護索引整體性。
• 避免使用觸發器
觸發器的功能通常可以用其他方式實現。在調試程序時觸發器可能成為干擾。假如你確實需要採用觸發器，你最好集中對它文檔化。
• 包含版本機制
建議你在資料庫中引入版本控制機制來確定使用中的資料庫的版本。無論如何你都要實現這一要求。時間一長，用戶的需求總是會改變的。最終可能會要求修改資料庫結構。雖然你可以通過檢查新欄位或者索引來確定資料庫結構的版本，但我發現把版本信息直接存放到資料庫中不更為方便嗎？。
• 給文本欄位留足餘量
ID 類型的文本欄位，比如客戶 ID 或定單號等等都應該設置得比一般想像更大，因為時間不長你多半就會因為要添加額外的字元而難堪不已。比方說，假設你的客戶 ID 為 10 位數長。那你應該把資料庫表欄位的長度設為 12 或者 13 個字元長。這算浪費空間嗎？是有一點，但也沒你想像的那麼多：一個欄位加長 3 個字元在有 1 百萬條記錄，再加上一點索引的情況下才不過讓整個資料庫多佔據 3MB 的空間。但這額外占據的空間卻無需將來重構整個資料庫就可以實現資料庫規模的增長了。身份證的號碼從 15 位變成 18 位就是最好和最慘痛的例子。
• 列[欄位]命名技巧
我們發現，假如你給每個表的列[欄位]名都採用統一的前綴，那麼在編寫 SQL 表達式的時候會得到大大的簡化。這樣做也確實有缺點，比如破壞了自動表連接工具的作用，後者把公共列[欄位]名同某些資料庫聯系起來，不過就連這些工具有時不也連接錯誤嘛。舉個簡單的例子，假設有兩個表：
Customer 和 Order。Customer 表的前綴是 cu_，所以該表內的子段名如下：cu_name_id、cu_surname、cu_initials 和cu_address 等。Order 表的前綴是 or_，所以子段名是：
or_order_id、or_cust_name_id、or_quantity 和 or_description 等。
這樣從資料庫中選出全部數據的 SQL 語句可以寫成如下所示：
Select * From Customer, Order Where cu_surname = "MYNAME" ;
and cu_name_id = or_cust_name_id and or_quantity = 1
在沒有這些前綴的情況下則寫成這個樣子（用別名來區分）：
Select * From Customer, Order Where Customer.surname = "MYNAME" ;
and Customer.name_id = Order.cust_name_id and Order.quantity = 1
第 1 個 SQL 語句沒少鍵入多少字元。但如果查詢涉及到 5 個表乃至更多的列[欄位]你就知道這個技巧多有用了。
6. 什麼是資料庫名稱還有用戶名和密碼
資料庫名稱就是創建資料庫時所命名的標識名字，用戶名和密碼登錄資料庫軟體的憑證。資料庫用戶即使用和共享資料庫資源的人。
database_name 資料庫的名稱。資料庫名稱在伺服器中必須唯一，並且符合標識符的規則。database_name最多可以包含 128 個字元，除非沒有為日誌指定邏輯名。
在SQL語句中有部分對資料庫的操作都依賴資料庫名來標識具體的資料庫，如：創建資料庫（Create DATABASE databasename）、刪除資料庫（drop database databasename）等，資料庫名（databasename）都作為重要的參數。
(6)2資料庫的命名規則有哪些擴展閱讀：
新資料庫的名稱。資料庫名稱在伺服器中必須唯一，並且符合標識符的規則。database_name最多可以包含 128 個字元，除非沒有為日誌指定邏輯名。
如果沒有指定日誌文件的邏輯名，則 Microsoft® SQL Server™ 會通過向database_name追加後綴來生成邏輯名。該操作要求database_name在 123 個字元之內，以便生成的日誌文件邏輯名少於 128 個字元。
ON，指定顯式定義用來存儲資料庫數據部分的磁碟文件（數據文件）。該關鍵字後跟以逗號分隔的 <filespec> 項列表，<filespec> 項用以定義主文件組的數據文件。
主文件組的文件列表後可跟以逗號分隔的 <filegroup> 項列表（可選），<filegroup> 項用以定義用戶文件組及其文件。
佔位符，表示可以為新資料庫指定多個文件。LOG ON，指定顯式定義用來存儲資料庫日誌的磁碟文件（日誌文件）。
該關鍵字後跟以逗號分隔的 <filespec> 項列表，<filespec> 項用以定義日誌文件。如果沒有指定 LOG ON，將自動創建一個日誌文件，該文件使用系統生成的名稱，大小為資料庫中所有數據文件總大小的 25%。