郵件資料庫設計

① 郵箱的資料庫表設計

這個簡單的郵件系統其實只需要兩個表
1個是用戶表,用來記錄郵件系統中的用戶信息和用戶設置
用戶表(用戶id，用戶姓名，注冊時間，用戶密碼，部門，。。。)其他信息根據需要自己添吧
另一個是郵件表,用來記錄具體的郵件內容
郵件表（郵件id，發件人id，收件人id，發件時間，郵件主題，郵件內容，閱讀狀態，郵件狀態）其中郵件狀態用來標記是否被刪除，用戶刪除的郵件在系統中其實並不是真正刪除，而是對用戶不可意見
而閱讀狀態則用來讓收件人看到哪些是還沒有閱讀的郵件

② 郵件資料庫設計

給你個建議. 欄位:用戶名,密碼.郵件名,郵件內容,附件,讀刪標志.

因為你不知道郵件的內容有多大,附件有多大.那你對這欄位的長度就無法的設定,你在建資料庫的時候就無法的定義.建議你設計兩個欄位:郵件內容路徑,附件路徑.只存放郵件存放的路徑.這樣路徑是可以預知的.比人d:/..../.../等.

欄位: 讀刪標志 就是這郵件是讀.未讀,刪除.等你可以自己設計.比如用00.表示未讀,01表示讀,02表示刪除.

當然其他欄位你也可以加的.關鍵我想你是對這個郵件存放在那裡不知道. 不用單獨表存放.你就設計一個欄位存放就好.這個欄位就存放 郵件的路徑.
明白了吧?

③ 資料庫設計的設計技巧

（需求分析階段）
1) 理解客戶需求，詢問用戶如何看待未來需求變化。讓客戶解釋其需求，而且隨著開發的繼續，還要經常詢問客戶保證其需求仍然在開發的目的之中。
2) 了解企業業務可以在以後的開發階段節約大量的時間。
3) 重視輸入輸出。
在定義資料庫表和欄位需求（輸入）時，首先應檢查現有的或者已經設計出的報表、查詢和視圖（輸出）以決定為了支持這些輸出哪些是必要的表和欄位。
舉例：假如客戶需要一個報表按照郵政編碼排序、分段和求和，你要保證其中包括了單獨的郵政編碼欄位而不要把郵政編碼糅進地址欄位里。
4) 創建數據字典和ER 圖表
ER 圖表和數據字典可以讓任何了解資料庫的人都明確如何從資料庫中獲得數據。ER圖對表明表之間關系很有用，而數據字典則說明了每個欄位的用途以及任何可能存在的別名。對sql表達式的文檔化來說這是完全必要的。
5) 定義標準的對象命名規范
資料庫各種對象的命名必須規范。 （資料庫邏輯設計）
表設計原則
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) 增加刪除標記欄位
在表中包含一個「刪除標記」欄位，這樣就可以把行標記為刪除。在關系資料庫里不要單獨刪除某一行；最好採用清除數據程序而且要仔細維護索引整體性。 （資料庫邏輯設計）
鍵選擇原則：
1) 鍵設計4 原則為
關聯欄位創建外鍵。
所有的鍵都必須唯一。
避免使用復合鍵。
外鍵總是關聯唯一的鍵欄位。
2) 使用系統生成的主鍵
設計資料庫的時候採用系統生成的鍵作為主鍵，那麼實際控制了資料庫的索引完整性。這樣，資料庫和非人工機制就有效地控制了對存儲數據中每一行的訪問。採用系統生成鍵作為主鍵還有一個優點：當擁有一致的鍵結構時，(不讓主鍵具有可更新性)
在確定採用什麼欄位作為表的鍵的時候，可一定要小心用戶將要編輯的欄位。通常的情況下不要選擇用戶可編輯的欄位作為鍵。
4) 可選鍵有時可做主鍵
把可選鍵進一步用做主鍵，可以擁有建立強大索引的能力。
索引使用原則：
索引是從資料庫中獲取數據的最高效方式之一。95%的資料庫性能問題都可以採用索引技術得到解決。
1) 邏輯主鍵使用唯一的成組索引，對系統鍵（作為存儲過程）採用唯一的非成組索引，對任何外鍵列採用非成組索引。考慮資料庫的空間有多大，表如何進行訪問，還有這些訪問是否主要用作讀寫。
2) 大多數資料庫都索引自動創建的主鍵欄位，但是可別忘了索引外鍵，它們也是經常使用的鍵，比如運行查詢顯示主表和所有關聯表的某條記錄就用得上。
3) 不要索引memo/note 欄位，不要索引大型欄位（有很多字元），這樣作會讓索引佔用太多的存儲空間。
4) 不要索引常用的小型表
不要為小型數據表設置任何鍵，假如它們經常有插入和刪除操作就更別這樣作了。對這些插入和刪除操作的索引維護可能比掃描表空間消耗更多的時間。 （資料庫邏輯設計）
1) 完整性實現機制：
實體完整性：主鍵
參照完整性：
父表中刪除數據：級聯刪除；受限刪除；置空值
父表中插入數據：受限插入；遞歸插入
父表中更新數據：級聯更新；受限更新；置空值
DBMS對參照完整性可以有兩種方法實現：外鍵實現機制（約束規則）和觸發器實現機制
用戶定義完整性：
NOT NULL；CHECK；觸發器
2) 用約束而非商務規則強制數據完整性
採用資料庫系統實現數據的完整性。這不但包括通過標准化實現的完整性而且還包括數據的功能性。在寫數據的時候還可以增加觸發器來保證數據的正確性。不要依賴於商務層保證數據完整性；它不能保證表之間（外鍵）的完整性所以不能強加於其他完整性規則之上。
3) 強制指示完整性
在有害數據進入資料庫之前將其剔除。激活資料庫系統的指示完整性特性。這樣可以保持數據的清潔而能迫使開發人員投入更多的時間處理錯誤條件。
4) 使用查找控制數據完整性
控制數據完整性的最佳方式就是限制用戶的選擇。只要有可能都應該提供給用戶一個清晰的價值列表供其選擇。這樣將減少鍵入代碼的錯誤和誤解同時提供數據的一致性。某些公共數據特別適合查找：國家代碼、狀態代碼等。
5) 採用視圖
為了在資料庫和應用程序代碼之間提供另一層抽象，可以為應用程序建立專門的視圖而不必非要應用程序直接訪問數據表。這樣做還等於在處理資料庫變更時給你提供了更多的自由。 1) 避免使用觸發器
觸發器的功能通常可以用其他方式實現。在調試程序時觸發器可能成為干擾。假如你確實需要採用觸發器，你最好集中對它文檔化。
2) 使用常用英語（或者其他任何語言）而不要使用編碼
在創建下拉菜單、列表、報表時最好按照英語名排序。假如需要編碼，可以在編碼旁附上用戶知道的英語。
3) 保存常用信息
讓一個表專門存放一般資料庫信息非常有用。在這個表裡存放資料庫當前版本、檢查/修復（對 Access）、關聯設計文檔的名稱、客戶等信息。這樣可以實現一種簡單機制跟蹤資料庫，當客戶抱怨他們的資料庫沒有達到希望的要求而與你聯系時，這樣做對非客戶機/伺服器環境特別有用。
4) 包含版本機制
在資料庫中引入版本控制機制來確定使用中的資料庫的版本。時間一長，用戶的需求總是會改變的。最終可能會要求修改資料庫結構。把版本信息直接存放到資料庫中更為方便。
5) 編制文檔
採用給表、列、觸發器等加註釋的資料庫工具。對開發、支持和跟蹤修改非常有用。
對資料庫文檔化，或者在資料庫自身的內部或者單獨建立文檔。這樣，當過了一年多時間後再回過頭來做第2 個版本，犯錯的機會將大大減少。
6) 測試、測試、反復測試
建立或者修訂資料庫之後，必須用用戶新輸入的數據測試數據欄位。最重要的是，讓用戶進行測試並且同用戶一道保證選擇的數據類型滿足商業要求。測試需要在把新資料庫投入實際服務之前完成。
7) 檢查設計
在開發期間檢查資料庫設計的常用技術是通過其所支持的應用程序原型檢查資料庫。換句話說，針對每一種最終表達數據的原型應用，保證你檢查了數據模型並且查看如何取出數據。

④ 如何進行資料庫的設計

資料庫設計(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) 檢查設計
在開發期間檢查資料庫設計的常用技術是通過其所支持的應用程序原型檢查資料庫。換句話說，針對每一種最終表達數據的原型應用，保證你檢查了數據模型並且查看如何取出數據。

⑤ 電子郵箱的資料庫設計怎麼做

用varchar類型

⑥ 關於OA系統，郵件模塊資料庫設計問題！

上機測試內容
1.計算機操作能力。
2.C語言程序設計能力。
3.項目開發能力。
4.開發工具的使用能力。
考試方式
1.考試形式包括筆試(180分鍾)和上機測試(60分鍾)。
2.筆試的試題包括選擇題和論述題兩種類型，其中在五分之一的選擇題用英文書寫，其餘選擇題和論述題用中文書寫。
考綱~~
基本要求
1.具有計算機及其應用的基礎知識。
2.熟悉計算機操作系統，軟體工程和資料庫的原理及其應用。
3.熟悉計算機體系結構、系統組成和性能評價的基礎和應用知識。
4.具有計算機網路和通信的基礎知識。
5.具有計算機應用項目開發的分析設計和組織實施的基本能力。
6.具有計算機應用系統安全性和保密性知識。
考試內容
一、計算機系統組成及工作原理
1. 基本概念:
⑴ 計算機系統的硬體組成。
⑵ 計算機系統的層次結構。
⑶ 計算機的主要性能指標。
2.運算方法基礎與運算器:
⑴ 數值數據在計算機中的表示。
⑵ 非數值數據在計算機中的表示。
⑶ 數據校驗碼。
⑷ 基本的算術運算。
⑸ 基本的邏輯運算。
⑹ 運算器的組成。
3.指令系統及控制器:
⑴ 指令格式和指令的定址方式。
⑵ 指令類型。
⑶ 控制器的組成。
⑷ CPU的總體結構。
⑸ 中斷系統。
4.存儲系統
⑴ 存儲系統原理。
⑵ 半導體隨機存儲器和只讀存儲器。
⑶ 主存儲器的組成與讀寫操作。
⑷ 外存儲器的工作原理。
5.輸入/輸出設備與輸入/輸出系統：
⑴ 常用輸入/輸出設備。。
⑵ 程序查詢方式。
⑶ 程序中斷方式。
⑷ DMA方式。
⑸ 通道方式。
⑹ 典型匯流排。
二、數據結構與演算法
1.基本概念:
⑴ 數據結構的基本概念。
⑵ 演算法的定義、性質、描述與演算法分析。
2.線性表:
⑴ 線性表的基本概念。
⑵ 線性表的順序存儲結構。
⑶ 線性表的鏈式存儲結構（單鏈表、循環鏈表、雙向鏈表。
3.數組:
⑴ 數組的基本概念（定義，基本操作）。
⑵ 數組的存儲方法。
⑶ 特殊矩陣的壓縮存儲。
4.堆棧與隊列:
⑴ 堆棧的基本概念與操作。
⑵ 堆棧的順序存儲結構。
⑶ 堆棧的鏈式存儲結構。
⑷ 隊列的基本概念與操作。
⑸ 隊列的順序存儲結構。
⑹ 隊列的鏈式存儲結構。
5.樹和二叉樹:
⑴ 樹的基本概念（定義，名詞術語）和存儲方法。
⑵ 二叉樹的基本概念及性質。
⑶ 二叉樹順序存儲結構與鏈式存儲結構。
⑷ 二叉樹的遍歷（前序遍歷，中序遍歷，後序遍歷，按層次遍歷）。
⑸ 線索二叉樹。
⑹ 二叉排序樹（建立與查找）。
6.圖:
⑴ 圖的基本概念（定義，分類，名詞術語）。
⑵ 圖的存儲方法（鄰接矩陣存儲方法，鄰接表存儲方法）。
⑶ 圖的遍歷（深度優先搜索，廣度優先搜索）。
⑷ 最小生成樹。
⑸ 最短路徑問題。
⑹ 拓撲排序。
7.文件及其查找:
⑴ 數據文件的基本概念。
⑵ 順序文件及其查找方法（順序查找方法，折半查找方法）。
⑶ 索引文件及其查找方法。
⑷ 散列文件及其查找方法。
8.內排序:
⑴ 排序的基本概念（定義，功能，分類）。
⑵ 插入排序方法。
⑶ 選擇排序方法。
⑷ 起泡排序方法。
⑸ 希爾排序方法。
⑹ 快速排序方法。
⑺ 堆排序方法。
⑻ 二路歸並排序方法。
三、離散數學
1.數理邏輯:
⑴ 命題、聯結詞及其命題符號化。
⑵ 命題公式及其分類。
⑶ 命題邏輯等值演算。
⑷ 析取範式與合取範式。
⑸ 命題邏輯推理理論。
⑹ 謂詞與量詞。
⑺ 謂詞公式與解釋。
⑻ 謂詞公式的分類。
⑼ 謂詞邏輯等值演算與前束範式。
⑽ 謂詞邏輯推理理論。
2.集合論:
⑴ 集合基本概念。
⑵ 集合的運算。
⑶ 基本的集合恆等式。
⑷ 有序對與卡氏積。
⑸ 二元關系。
⑹ 關系哪妗⑾拗萍跋蟆?
⑺ 關系的性質。
⑻ 關系的閉包。
⑼ 關系的復合。
⑽ 等價關系與劃分。
⑾ 偏序關系與哈斯圖。
⑿ 函數及其性質。
⒀ 復合函數與反函數。
⒁ 自然數與自然數集合。
⒂ 集合之間的等勢與優勢。
⒃ 集合的基數。
3.代數結構:
⑴ 代數運算及其性質。
⑵ 代數系統。
⑶ 代數系統的同態與同構。
⑷ 半群與群。
⑸ 子群與陪群。
⑹ 正規子群與商群。
⑺ 循環群與置換群。
⑻ 環與域。
⑼ 格與布爾代數。
4.圖論:
⑴ 無向圖與有向圖。
⑵ 路、迴路與圖的連通性。
⑶ 圖的矩陣表示。
⑷ 二部圖與完全二部圖。
⑸ 歐拉圖與哈密爾頓圖。
⑹ 平面圖。
⑺ 無向樹及其性質。
⑻ 生成樹。
⑼ 根樹及其應用。
四、操作系統
1.操作系統基本概念:
⑴ 操作系統的功能。
⑵ 操作系統的基本類型。
⑶ 操作系統的介面。
2.進程管理:
⑴ 進程、線程與進程管理。
⑵ 進程式控制制。
⑶ 進程調度。
⑷ 進程通信。
⑸ 死鎖。
3.作業管理:
⑴ 作業與作業管理。
⑵ 作業狀態與調度。
4.存儲管理:
⑴ 存儲與存儲管理。
⑵ 虛擬存儲原理。
⑶ 頁式存儲。
⑷ 段式存儲。
⑸ 段頁式存儲。
⑹ 局部性原理與工作集概念。
5.文件管理:
⑴ 文件與文件管理。
⑵ 文件的分類。
⑶ 文件結構與存取方式。
⑷ 文件目錄結構。
⑸ 文件存儲管理。
⑹ 文件存取控制。
⑺ 文件的使用。
6.設備管理:
⑴ 設備與設備分類。
⑵ 輸入輸出控制方式。
⑶ 通道技術。
⑷ 緩沖技術。
⑸ 設備分配技術與SPOOLing系統。
⑹ 磁碟調度。
7.典型操作系統的使用:
⑴ UNIX的特點與使用。
⑵ Linux的特點與使用。
⑶ Windows的特點與使用。
五、軟體工程
1.軟體工程基本概念:
⑴ 軟體與軟體危機。
⑵ 軟體工程定義。
⑶ 軟體生命周期。
⑷ 軟體過程模型。
2.結構化分析與設計:
⑴ 問題定義與可行性研究。
⑵ 軟體需求分析。
⑶ 數據流程圖與數據字典。
⑷ 軟體體系結構設計。
⑸ 概要設計與詳細設計。
⑹ 模塊結構設計與數據結構設計。
⑺ 用戶界面設計。
3.原型化開發方法:
⑴ 原型化開發的基本原理。
⑵ 原型化開發模型。
⑶ 原型化開發過程。
⑷ 軟體復用。

⑦ 請問如何為一些特定的郵箱資料庫更新設計_lotus notes

使用文件轉換的工具，並配合其參數就可以實現。
文件轉換工具命令的格式是：
load convert [-r | -l | -f | -m] mailfilepath existingtemplatename newtemplatefilename
其中，-r是轉換一個特定目錄下的子目錄的文件；-l是創建了一個文本的列表；-f是為資料庫的文本列表中定義的資料庫進行升級或更新；-m是轉換郵箱文件或為IMAP使用的文件；mailfilepath是指定所需升級的文件；existingtemplatename是指定一個特定的文件設計(例如，只是使用R4.6設計的郵件文件)；newtemplatefilename是定義了用來更新的文件。
1.更新一個單獨的郵箱資料庫
例如，更新在＼MAIL子目錄下的USER.NSF。此郵件轉換工具將會替代現有的郵件模版- 無論是哪一個模版文件被使用- 用MAIL50.NTF(R5的郵箱模版)來替換。輸入的命令是：
load convert mail＼user.nsf * mail50.ntf
2.更新在一個子目錄下的所有郵箱文件
例如，更新在＼MAIL子目錄下的所有的資料庫文件，原有的資料庫是使用的StdR45Mail（R4.5的郵箱模版），需要被替換設計為R5的郵箱模版- StdR50Mail (MAIL50.NTF)。輸入的命令是：
load convert mail＼*.nsf stdr45mail mail50.ntf
3.升級在一個目錄和它的子目錄下的所有資料庫
例如，更新在＼MAIL子目錄下以及＼MAIL子目錄下的子目錄的所有的資料庫文件（例如，C:＼NOTES＼DATA＼MAIL＼GROUP1，C:＼NOTES＼DATA＼MAIL＼GROUP2，和C:＼NOTES＼DATA＼MAIL＼GROUP），需要被替換設計為R5的郵箱模版- StdR50Mail (MAIL50.NTF)。輸入的命令是：
load convert -r mail＼*.nsf * mail50.ntf
4.升級列在一個文本文件中的所有郵箱資料庫
你可以創建一個文本文件，把你需要升級的資料庫都列在裡面，用它和文件轉換工具來升級只是列在文本文件中的這些資料庫。例如，你創建了一個叫做MAILLIST.TXT的文本文件，並把需要升級的資料庫都列在裡面，把此文本文件保存在C:＼TEMP的目錄下。需要被替換設計為R5的郵箱模版- StdR50Mail (MAIL50.NTF)。輸入的命令是：
load convert -f c:＼temp＼maillist.txt std* mail50.ntf
5.創建一個文本文件，並把所有的郵件文件列在一個目錄下
你可以使用文件轉換工具來創建一個文本文件，此文件將列出伺服器上主要的郵箱資料庫（它不能列出郵箱文件的復本資料庫）。例如，創建了一個叫做MAILLIST.TXT的文本文件，在 C:＼TEMP的目錄下。此MAILLIST.TXT的文件中列出了在伺服器上的主要的郵箱資料庫（排除了郵箱文件的復本資料庫）。當你使用選項來創建此文本文件後，你可以使用此文件來更新在此文件中列出的文件。創建文本文件的命令是：
load convert -l c:＼temp＼maillist.txt
6.為使用IMAP的用戶轉換郵件文件
當你決定為使用IMAP的NOTES用戶轉換郵件文件時，運行文件轉換工具來激活IMAP在郵件文件中特定的功能。例如，需要為＼MAIL子目錄下的USER.NSF替換設計為IMAP使用的模版。輸入的命令是：
注意：當你使用通配符 * 進行更新郵箱文件模版時，一定要保證在此目錄下（或指定的子目錄下）的資料庫都是郵件文件。否則，非郵件資料庫將會被替換設計為R5的郵件模版。

⑧ 基於sql server 2008的收發郵件系統資料庫設計。下面是要求，麻煩大神幫忙設計一個！

/**
* Created by jifang on 15/12/27.
*/
public class TestCase {

public void test1() {
System.out.println("test1");
}

@TestableException(ArithmeticException.class)
public void test2() throws IOException {
int i = 1 / 0;
System.out.println(i);
}

@TestableException(ArithmeticException.class)
public void test3() {
System.out.println("test3");
throw new RuntimeException("我test3出錯啦...");
}

public void test4() {
System.out.println("test4");
}

@TestableException({ArithmeticException.class, IOException.class})
public void test5() throws FileNotFoundException {
FileInputStream stream = new FileInputStream("xxxx");
}

@Testable
public void test6() {
System.out.println("test6");
}
}

⑨ 郵箱的資料庫應該如何設計

你要分清狀態的管理！就可以了！一張表也可以！
一張表實現，像你說的標記位置不同就可以了，只要ID，名稱，位置在那個郵箱，狀態是否閱讀就可以了哦！
無論記錄多與少還是與你系統需求有關。如果方便管理以後郵箱升級，系統升級還是多幾張表還是比較好的哦！

⑩ 求郵件系統的資料庫設計表

我有一套,幾用PHP寫的,MYSQL資料庫