公司資料庫表

㈠ 在公司人事管理資料庫中使用數據表Employees 來記錄員工信息。

根據選項多次強調「兩列」，個人感覺只能選A。
規則與CHECK不同於：
規則可使用於多列，但每列只允許定義一次；
CHECK只用於一列，但一列可定義多個CHECK。

㈡ 公司內部系統的oracle資料庫表怎麼對接

建議建立中間表來實現，不建議也不需要設置鍵值關聯，建了反而會有問題
最簡單的實現方式大概思路就是設計一個中間表（欄位只要雙方約定好就可以了），通過dblink的方式，他們系統往中間表裡插入數據，你們從中間表裡獲取數據，這樣大家互不影響

㈢ 如何用access建立公司員工資料庫

很簡單的，03一般使用向導來建立資料庫就行了，07里初始都是現成的模板來新建，如果都不是你希望使用的模板，點offfice按扭，點新建，在右側會出現新建文件保存的目錄，確定一下就行了，

㈣ 某公司的人事系統資料庫中有三張表： 員工表（EMP）,部門表（DEPT）,工資表（SALARY） EMP表結構如下

SELECT
main.dept_name as 部門名稱,
count(*) as 在職員工數,
sum(acu_salary) as 實發工資總額
FROM
dept main
INNER JOIN emp a ON main.dept_code = a.dept_code
INNER JOIN salary b ON a.emp_id = b.emp_id
WHERE
-- 1為有效標識
main.alive_flag = '1'
AND a.alive_flag = '1'
AND b.alive_flag = '1'
AND b.`month` = '201101'
GROUP BY
a.dept_code
HAVING
count(*) > 5

㈤ 資料庫表與表之間的關系

表與表之間一般存在三種關系，即一對一，一對多，多對多關系。

例如:一個人可以擁有多輛汽車，要求查詢某個人擁有的所有車輛。
分析：這種情況其實也可以採用 一張表，但因為一個人可以擁有多輛汽車，如果採用一張表，會造成冗餘信息過多。好的設計方式是，人和車輛分別單獨建表，那麼如何將兩個表關聯呢？有個巧妙的方法，在車輛的表中加個外鍵欄位(人的編號)即可。

例如：學生選課，一個學生可以選修多門課程，每門課程可供多個學生選擇。
分析：這種方式可以按照類似一對多方式建表，但冗餘信息太多，好的方式是實體和關系分離並單獨建表，實體表為學生表和課程表，關系表為選修表，其中關系表採用聯合主鍵的方式(由學生表主鍵和課程表主鍵組成)建表。

什麼是視圖？

在 sql 中，視圖是基於 SQL 語句的結果集的可視化的表。

第一點：
使用視圖，可以定製用戶數據，聚焦特定的數據。

解釋：
在實際過程中，公司有不同角色的工作人員，我們以銷售公司為例的話，
采購人員，可以需要一些與其有關的數據，而與他無關的數據，對他沒
有任何意義，我們可以根據這一實際情況，專門為采購人員創建一個視
圖，以後他在查詢數據時，只需select * from view_caigou 就可以啦。

第二點：使用視圖，可以簡化數據操作。

解釋：我們在使用查詢時，在很多時候我們要使用聚合函數，同時還要
顯示其它欄位的信息，可能還會需要關聯到其它表，這時寫的語句可能
會很長，如果這個動作頻繁發生的話，我們可以創建視圖，這以後，我
們只需要select * from view1就可以啦～，是不是很方便呀～

第三點：使用視圖，基表中的數據就有了一定的安全性

因為視圖是虛擬的，物理上是不存在的，只是存儲了數據的集合，我們可以
將基表中重要的欄位信息，可以不通過視圖給用戶，視圖是動態的數據的集
合，數據是隨著基表的更新而更新。同時，用戶對視圖，不可以隨意的更改
和刪除，可以保證數據的安全性。

第四點：可以合並分離的數據，創建分區視圖

隨著社會的發展，公司的業務量的不斷的擴大，一個大公司，下屬都設有很
多的分公司，為了管理方便，我們需要統一表的結構，定期查看各公司業務
情況，而分別看各個公司的數據很不方便，沒有很好的可比性，如果將這些
數據合並為一個表格里，就方便多啦，這時我們就可以使用union關鍵字，
將各分公司的數據合並為一個視圖。

以上，就是我認為視圖的作用，實際上很多公司都使用視圖來查詢數據的。

內連接: 只連接匹配的行
SELECT * from gradeclass gc inner join grade g on gc.grade_id=g.Id，
左外連接: 包含左邊表的全部行（不管右邊的表中是否存在與它們匹配的行），以及右邊表中全部匹配的行
select * from grade g rigth OUTER JOIN gradeclass g on g.grade_id=gc.Id（這里的outer可以省略）
右外連接: 包含右邊表的全部行（不管左邊的表中是否存在與它們匹配的行），以及左邊表中全部匹配的行
select * from grade g rigth OUTER JOIN gradeclass g on g.grade_id=gc.Id（這里的outer可以省略）
全外連接: 包含左、右兩個表的全部行，不管另外一邊的表中是否存在與它們匹配的行。
交叉連接: 生成笛卡爾積－它不使用任何匹配或者選取條件，而是直接將一個數據源中的每個行與另一個數據源的每個行都一一匹配

㈥ 求教公司的資料庫構建有哪些要素

簡述資料庫設計過程—希望可以幫你

資料庫設計(Database Design)是指對於一個給定的應用環境，構造最優的資料庫模式，建立資料庫及其應用系統，使之能夠有效地存儲數據，滿足各種用戶的應用需求（信息要求和處理要求）。

在資料庫領域內，常常把使用資料庫的各類系統統稱為資料庫應用系統。

一、資料庫和信息系統
(1)資料庫是信息系統的核心和基礎，把信息系統中大量的數據按一定的模型組織起來，提供存儲、維護、檢索數據的
功能，使信息系統可以方便、及時、准確地從資料庫中獲得所需的信息。
(2)資料庫是信息系統的各個部分能否緊密地結合在一起以及如何結合的關鍵所在。
(3)資料庫設計是信息系統開發和建設的重要組成部分。
(4)資料庫設計人員應該具備的技術和知識：
資料庫的基本知識和資料庫設計技術
計算機科學的基礎知識和程序設計的方法和技巧
軟體工程的原理和方法
應用領域的知識

二、資料庫設計的特點
資料庫建設是硬體、軟體和干件的結合
三分技術，七分管理，十二分基礎數據
技術與管理的界面稱之為逗干件地
資料庫設計應該與應用系統設計相結合
結構（數據）設計：設計資料庫框架或資料庫結構
行為（處理）設計：設計應用程序、事務處理等
結構和行為分離的設計
傳統的軟體工程忽視對應用中數據語義的分析和抽象，只要有可能就盡量推遲數據結構設計的決策早期的資料庫設計致力於數據模型和建模方法研究，忽視了對行為的設計
如圖：

三、資料庫設計方法簡述
手工試湊法
設計質量與設計人員的經驗和水平有直接關系
缺乏科學理論和工程方法的支持，工程的質量難以保證
資料庫運行一段時間後常常又不同程度地發現各種問題，增加了維護代價
規范設計法
手工設計方
基本思想
過程迭代和逐步求精
規范設計法(續)
典型方法：
(1)新奧爾良（New Orleans）方法：將資料庫設計分為四個階段
S.B.Yao方法：將資料庫設計分為五個步驟
I.R.Palmer方法：把資料庫設計當成一步接一步的過程
(2)計算機輔助設計
ORACLE Designer 2000
SYBASE PowerDesigner

四、資料庫設計的基本步驟
資料庫設計的過程(六個階段)
1.需求分析階段
准確了解與分析用戶需求（包括數據與處理）
是整個設計過程的基礎，是最困難、最耗費時間的一步
2.概念結構設計階段
是整個資料庫設計的關鍵
通過對用戶需求進行綜合、歸納與抽象，形成一個獨立於具體DBMS的概念模型
3.邏輯結構設計階段
將概念結構轉換為某個DBMS所支持的數據模型
對其進行優化
4.資料庫物理設計階段
為邏輯數據模型選取一個最適合應用環境的物理結構（包括存儲結構和存取方法）
5.資料庫實施階段
運用DBMS提供的數據語言、工具及宿主語言，根據邏輯設計和物理設計的結果
建立資料庫，編制與調試應用程序，組織數據入庫，並進行試運行
6.資料庫運行和維護階段
資料庫應用系統經過試運行後即可投入正式運行。
在資料庫系統運行過程中必須不斷地對其進行評價、調整與修改
設計特點:
在設計過程中把資料庫的設計和對資料庫中數據處理的設計緊密結合起來將這兩個方面的需求分析、抽象、設計、實現在各個階段同時進行，相互參照，相互補充，以完善兩方面的設計

設計過程各個階段的設計描述：
如圖：

五、資料庫各級模式的形成過程
1.需求分析階段：綜合各個用戶的應用需求
2.概念設計階段：形成獨立於機器特點，獨立於各個DBMS產品的概念模式(E-R圖)
3.邏輯設計階段：首先將E-R圖轉換成具體的資料庫產品支持的數據模型，如關系模型，形成資料庫邏輯模式；然後根據用戶處理的要求、安全性的考慮，在基本表的基礎上再建立必要的視圖(View)，形成數據的外模式
4.物理設計階段：根據DBMS特點和處理的需要，進行物理存儲安排，建立索引，形成資料庫內模式

六、資料庫設計技巧

1. 設計資料庫之前（需求分析階段）
1) 理解客戶需求，詢問用戶如何看待未來需求變化。讓客戶解釋其需求，而且隨著開發的繼續，還要經常詢問客戶保證其需求仍然在開發的目的之中。
2) 了解企業業務可以在以後的開發階段節約大量的時間。
3) 重視輸入輸出。
在定義資料庫表和欄位需求（輸入）時，首先應檢查現有的或者已經設計出的報表、查詢和視圖（輸出）以決定為了支持這些輸出哪些是必要的表和欄位。
舉例：假如客戶需要一個報表按照郵政編碼排序、分段和求和，你要保證其中包括了單獨的郵政編碼欄位而不要把郵政編碼糅進地址欄位里。
4) 創建數據字典和ER 圖表
ER 圖表和數據字典可以讓任何了解資料庫的人都明確如何從資料庫中獲得數據。ER圖對表明表之間關系很有用，而數據字典則說明了每個欄位的用途以及任何可能存在的別名。對SQL 表達式的文檔化來說這是完全必要的。
5) 定義標準的對象命名規范
資料庫各種對象的命名必須規范。

2. 表和欄位的設計（資料庫邏輯設計）
表設計原則
1) 標准化和規范化
數據的標准化有助於消除資料庫中的數據冗餘。標准化有好幾種形式，但Third Normal Form（3NF）通常被認為在性能、擴展性和數據完整性方面達到了最好平衡。簡單來說，遵守3NF 標準的資料庫的表設計原則是：逗One Fact in One Place地即某個表只包括其本身基本的屬性，當不是它們本身所具有的屬性時需進行分解。表之間的關系通過外鍵相連接。它具有以下特點：有一組表專門存放通過鍵連接起來的關聯數據。
舉例：某個存放客戶及其有關定單的3NF 資料庫就可能有兩個表：Customer 和Order。Order 表不包含定單關聯客戶的任何信息，但表內會存放一個鍵值，該鍵指向Customer 表裡包含該客戶信息的那一行。
事實上，為了效率的緣故，對表不進行標准化有時也是必要的。
2) 數據驅動
採用數據驅動而非硬編碼的方式，許多策略變更和維護都會方便得多，大大增強系統的靈活性和擴展性。
舉例，假如用戶界面要訪問外部數據源（文件、XML 文檔、其他資料庫等），不妨把相應的連接和路徑信息存儲在用戶界面支持表裡。還有，如果用戶界面執行工作流之類的任務（發送郵件、列印信箋、修改記錄狀態等），那麼產生工作流的數據也可以存放在資料庫里。角色許可權管理也可以通過數據驅動來完成。事實上，如果過程是數據驅動的，你就可以把相當大的責任推給用戶，由用戶來維護自己的工作流過程。
3) 考慮各種變化
在設計資料庫的時候考慮到哪些數據欄位將來可能會發生變更。
舉例，姓氏就是如此（注意是西方人的姓氏，比如女性結婚後從夫姓等）。所以，在建立系統存儲客戶信息時，在單獨的一個數據表裡存儲姓氏欄位，而且還附加起始日和終止日等欄位，這樣就可以跟蹤這一數據條目的變化。

欄位設計原則
4) 每個表中都應該添加的3 個有用的欄位
dRecordCreationDate，在VB 下默認是Now()，而在SQL Server • 下默認為GETDATE()
sRecordCreator，在SQL Server 下默認為NOT NULL DEFAULT • USER
nRecordVersion，記錄的版本標記；有助於准確說明記錄中出現null 數據或者丟失數據的原因 •
5) 對地址和電話採用多個欄位
描述街道地址就短短一行記錄是不夠的。Address_Line1、Address_Line2 和Address_Line3 可以提供更大的靈活性。還有，電話號碼和郵件地址最好擁有自己的數據表，其間具有自身的類型和標記類別。
6) 使用角色實體定義屬於某類別的列
在需要對屬於特定類別或者具有特定角色的事物做定義時，可以用角色實體來創建特定的時間關聯關系，從而可以實現自我文檔化。
舉例：用PERSON 實體和PERSON_TYPE 實體來描述人員。比方說，當John Smith, Engineer 提升為John Smith, Director 乃至最後爬到John Smith, CIO 的高位，而所有你要做的不過是改變兩個表PERSON 和PERSON_TYPE 之間關系的鍵值，同時增加一個日期/時間欄位來知道變化是何時發生的。這樣，你的PERSON_TYPE 表就包含了所有PERSON 的可能類型，比如Associate、Engineer、Director、CIO 或者CEO 等。還有個替代辦法就是改變PERSON 記錄來反映新頭銜的變化，不過這樣一來在時間上無法跟蹤個人所處位置的具體時間。
7) 選擇數字類型和文本類型盡量充足
在SQL 中使用smallint 和tinyint 類型要特別小心。比如，假如想看看月銷售總額，總額欄位類型是smallint，那麼，如果總額超過了$32,767 就不能進行計算操作了。
而ID 類型的文本欄位，比如客戶ID 或定單號等等都應該設置得比一般想像更大。假設客戶ID 為10 位數長。那你應該把資料庫表欄位的長度設為12 或者13 個字元長。但這額外占據的空間卻無需將來重構整個資料庫就可以實現資料庫規模的增長了。
8) 增加刪除標記欄位
在表中包含一個逗刪除標記地欄位，這樣就可以把行標記為刪除。在關系資料庫里不要單獨刪除某一行；最好採用清除數據程序而且要仔細維護索引整體性。

3. 選擇鍵和索引（資料庫邏輯設計）
鍵選擇原則：
1) 鍵設計4 原則
為關聯欄位創建外鍵。 •
所有的鍵都必須唯一。 •
避免使用復合鍵。 •
外鍵總是關聯唯一的鍵欄位。 •
2) 使用系統生成的主鍵
設計資料庫的時候採用系統生成的鍵作為主鍵，那麼實際控制了資料庫的索引完整性。這樣，資料庫和非人工機制就有效地控制了對存儲數據中每一行的訪問。採用系統生成鍵作為主鍵還有一個優點：當擁有一致的鍵結構時，找到邏輯缺陷很容易。
3) 不要用用戶的鍵(不讓主鍵具有可更新性)
在確定採用什麼欄位作為表的鍵的時候，可一定要小心用戶將要編輯的欄位。通常的情況下不要選擇用戶可編輯的欄位作為鍵。
4) 可選鍵有時可做主鍵
把可選鍵進一步用做主鍵，可以擁有建立強大索引的能力。

索引使用原則：
索引是從資料庫中獲取數據的最高效方式之一。95%的資料庫性能問題都可以採用索引技術得到解決。
1) 邏輯主鍵使用唯一的成組索引，對系統鍵（作為存儲過程）採用唯一的非成組索引，對任何外鍵列採用非成組索引。考慮資料庫的空間有多大，表如何進行訪問，還有這些訪問是否主要用作讀寫。
2) 大多數資料庫都索引自動創建的主鍵欄位，但是可別忘了索引外鍵，它們也是經常使用的鍵，比如運行查詢顯示主表和所有關聯表的某條記錄就用得上。
3) 不要索引memo/note 欄位，不要索引大型欄位（有很多字元），這樣作會讓索引佔用太多的存儲空間。
4) 不要索引常用的小型表
不要為小型數據表設置任何鍵，假如它們經常有插入和刪除操作就更別這樣作了。對這些插入和刪除操作的索引維護可能比掃描表空間消耗更多的時間。

4. 數據完整性設計（資料庫邏輯設計）
1) 完整性實現機制：
實體完整性：主鍵
參照完整性：
父表中刪除數據：級聯刪除；受限刪除；置空值
父表中插入數據：受限插入；遞歸插入
父表中更新數據：級聯更新；受限更新；置空值
DBMS對參照完整性可以有兩種方法實現：外鍵實現機制（約束規則）和觸發器實現機制
用戶定義完整性：
NOT NULL；CHECK；觸發器
2) 用約束而非商務規則強制數據完整性
採用資料庫系統實現數據的完整性。這不但包括通過標准化實現的完整性而且還包括數據的功能性。在寫數據的時候還可以增加觸發器來保證數據的正確性。不要依賴於商務層保證數據完整性；它不能保證表之間（外鍵）的完整性所以不能強加於其他完整性規則之上。
3) 強制指示完整性
在有害數據進入資料庫之前將其剔除。激活資料庫系統的指示完整性特性。這樣可以保持數據的清潔而能迫使開發人員投入更多的時間處理錯誤條件。
4) 使用查找控制數據完整性
控制數據完整性的最佳方式就是限制用戶的選擇。只要有可能都應該提供給用戶一個清晰的價值列表供其選擇。這樣將減少鍵入代碼的錯誤和誤解同時提供數據的一致性。某些公共數據特別適合查找：國家代碼、狀態代碼等。
5) 採用視圖
為了在資料庫和應用程序代碼之間提供另一層抽象，可以為應用程序建立專門的視圖而不必非要應用程序直接訪問數據表。這樣做還等於在處理資料庫變更時給你提供了更多的自由。

5. 其他設計技巧
1) 避免使用觸發器
觸發器的功能通常可以用其他方式實現。在調試程序時觸發器可能成為干擾。假如你確實需要採用觸發器，你最好集中對它文檔化。
2) 使用常用英語（或者其他任何語言）而不要使用編碼
在創建下拉菜單、列表、報表時最好按照英語名排序。假如需要編碼，可以在編碼旁附上用戶知道的英語。
3) 保存常用信息
讓一個表專門存放一般資料庫信息非常有用。在這個表裡存放資料庫當前版本、最近檢查/修復（對Access）、關聯設計文檔的名稱、客戶等信息。這樣可以實現一種簡單機制跟蹤資料庫，當客戶抱怨他們的資料庫沒有達到希望的要求而與你聯系時，這樣做對非客戶機/伺服器環境特別有用。
4) 包含版本機制
在資料庫中引入版本控制機制來確定使用中的資料庫的版本。時間一長，用戶的需求總是會改變的。最終可能會要求修改資料庫結構。把版本信息直接存放到資料庫中更為方便。
5) 編制文檔
對所有的快捷方式、命名規范、限制和函數都要編制文檔。
採用給表、列、觸發器等加註釋的資料庫工具。對開發、支持和跟蹤修改非常有用。
對資料庫文檔化，或者在資料庫自身的內部或者單獨建立文檔。這樣，當過了一年多時間後再回過頭來做第2 個版本，犯錯的機會將大大減少。
6) 測試、測試、反復測試
建立或者修訂資料庫之後，必須用用戶新輸入的數據測試數據欄位。最重要的是，讓用戶進行測試並且同用戶一道保證選擇的數據類型滿足商業要求。測試需要在把新資料庫投入實際服務之前完成。
7) 檢查設計
在開發期間檢查資料庫設計的常用技術是通過其所支持的應用程序原型檢查資料庫。換句話說，針對每一種最終表達數據的原型應用，保證你檢查了數據模型並且查看如何取出數據。

㈦ 新到公司，發現資料庫表建立的時候沒有主鍵與表與表之間沒有外鍵

很多優秀的項目都沒有主外鍵關系的

舉個例子，一個張用戶表，一張訂單表，建立主外鍵關系
現在要刪除這個用戶，但是用戶曾經有過訂單（訂單不能刪除），你該怎麼刪除

約束表間關系的除了「主外鍵」，還有程序的邏輯性，觸發器也可以

㈧ 如何用SQL2005建立一個簡單的公司資料庫

一份設計合理的資料庫，對程序開發可以達到事半功倍的效果，對於後期維護、二次開發的重要性更是不言而喻。

數據設計、實現過程中的注意事件（個人觀點）：

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表中用戶自定義的錯誤消息即可。

------------------------------------------