接着上一篇
1、一般來說每個表都應該建立一個主鍵，主鍵也是主索引，大部分主鍵都建立在一個字段之上，但並不是說主鍵就只能是一個字段，它也可以建立在多個字段上。比如訂單我們分成了“訂單表”和“訂單明細表”兩個表，在“訂單表”中我們用“訂單號”作爲主鍵，而在“訂單明細表”中我們就可以用“訂單號”和“產品編號”兩個字段來做爲主鍵。
根據微軟官方的建議是儘量使用自動編號字段來作爲主鍵字段（自動編號這種數據類型的用處也就主要是用在這裏），不過並不是所有的時候都適用，還是得根據實際情況而定。一般使用自動編號作爲主鍵，主要也就是用來和其它表建立關係之用，像在錄入窗體中一般無須顯示出來。使用自動編號的好處是它的數據由數據庫引擎自動維護，並且不可修改，我們只要拿來用即可，而無須去關心在添加、修改數據時候要怎麼處理它。不便之處是它只會在使用過後最大編號上自動加1，如果我們刪除了某些編號，這些編號不會被重續填補。
2、對於經常用來查詢的字段我們可以對其建立索引。索引建立的原則是，儘量只對數據小且基本不存在空記錄的字段建立索引。但是索引不能建的太多，否則不但不能提高查詢速度，反而會造成系統對索引維護的複雜性，反而降低了性能。索引一般都是建立於比較小的數據類型字段上，如日期、數字型字段；如果是文本型字段，字段大小不應太大，一般字段大小不應該超過50，否則就要考慮建索引的必要性了；而備註、OLE對象字段則完全不允許建立索引。
3、剛入手時，我們可以通過實際中用到的報表來反推分析需要建立哪些表，以及表中大致有哪些字段。表一般主要有兩大類，一類就是存放諸如產品、員工、客戶信息的基礎表，其它表中的數據都是由這些基本數據組合而來。產品、員工、客戶這三個表相對於訂單表，訂單表就屬於第二層的業務表，我們往這類表中填入數據的時候，大部分的數據都要從前面的基礎表中取得。當然實際應用時根據業務流程的複雜程度，可能還會有第三層、第四層、第N層，這個只是一個泛化的分類方式。
4、除關係字段外的在基礎表中已有的字段，不應該在其它表中重複出現。比如產品表中保存了所有的產品信息，這樣在訂單明細表中除了產品表的主鍵字段外不應該再有其它在產品表中已有的字段。在應用時如果需要在訂單明細中顯示出這些信息，我們可以通過關係建立查詢，通過查詢從產品表中取得相應數據。
5、對相關的表應該建立關係，並參照完整性，這樣才能保證數據的有效性。關係的主要作用是消除數據冗餘，以及方便建立查詢。很多初學者對關係不理解或不重視，也就根本不去關注，造成了設計的查詢過於雜亂，效率低下，而且建立的數據庫中很容易出現無效和無用的數據。比如訂單表和訂單明細表之間，如果沒有建立關係並參照完整性，當刪除了訂單表中的數據時，訂單明細表中的相關記錄依然存在，這就明顯造成了無用數據。而如果我們在客戶表中修改了客戶的名稱，而沒有用關係中的參照完整性來確保數據完整，這樣就可能會造成此客戶的相關訂單數據就從正常的查詢中找不出來了。
對於使用可更新字段作爲主鍵的，還應該在建立關係時選中級聯更新。級聯更新的作用就是，如果訂單表中是通過客戶名稱和客戶表建立關係的，當我們修改了客戶表中的客戶名稱時，訂單表中的客戶名稱就會被自動更改。至於級聯刪除功能，這個要根據情況而定，比如訂單表和訂單明細表就可以選中級聯刪除，這樣我們刪除訂單表中的訂單記錄時，訂單明細表中和其它相關的訂單明細記錄就會被自動刪除。但對於像客戶表和客戶類別表這樣的，就不要設置級聯刪除了，否則一旦刪除了某個客戶類別，所有該類別的客戶資料都會刪除，哭都沒地方哭。因此級聯刪除功能對於比較重要的數據時儘量不要使用，確定要刪除的話，可以以先刪除相關子表中的記錄，再刪除主表中的記錄的方式來進行。
爲什麼要一再強調數據的有效性？這個問題其實答案很明顯。只有使用有效準確的數據才能從中分析出我們想要的信息，數據庫的作用就是通過對數據的嚴格細分和有效性驗證，來保證數據的準確和詳盡，我們才能從中分析出更多想要的信息。比如我們要統計針對某個客戶的訂單銷售額，則客戶表和訂單表之間是通過客戶名稱來關聯的。這樣一來如果我們在訂單表中某條或某幾條記錄中將客戶名稱輸錯了或進行了修改，但我們並沒有通過參照完整性去維護數據的有效性，表中的客戶名稱和我們統計時輸入的做爲查詢條件的客戶名稱不匹配，最終統計出來的銷售額自然也就是根本不正確，我們得不到正確的信息。類似這樣的情況，我們不但不會因爲使用數據庫提升工作效率和方便管理，反而會對我們的工作造成誤導，甚至可能因此造成損失。
6、對於數據的有效性驗證應該儘量交給數據庫引擎去處理。也就是在建表的時候就應該儘量設計好，而不是在窗體中通過代碼去處理，後者的有效性是不容易保證的。
把數據庫驗證交給數據庫引擎去處理，我們就可以省去很多重複的工作，只需要捕獲相應的錯誤就並對用戶進行提示，以及做出相應的處理就行了。否則如果全都放在窗體中去用代碼進行每一項有效性驗證的話，將是一個累死人的活兒。在表這一層次進行有效性驗證是最有效也是最可靠的方式，不會產生寫代碼時沒有考慮周全或不可預知的原因而造成的數據非正常更新、插入、刪除等情況。
在字段的有效性規則中我們可以使用所有的能在Access中使用的邏輯條件運算符，如=、>、>=、<、<=、Like、In、Between…And等。除了那種跨字段的有效性驗證（如交貨日期不能早於下單日期）以外，我們幾乎可以進行基於單個字段的所有驗證。
7、字段應當儘量使用最小的、最適合的數據類型和字段大小。如產品數量字段就應該使用整型或長整型的數據類型，而不是去用單精度、雙精度的數據類型；而像員工表中的員工姓名一般不可能超過10個字符（當然某些國家或民族的人的名字念一遍要歇幾次氣的那種不算_，我們這裏說的只是中國人的名字），所以我們就沒有必要把字段大小設成50或255，這樣做會浪費存儲空間和降低性能。而且當我們要對數據進行計算統計排序等處理的時候，也必須使用正確的數據類型才行，每種數據類型的比較計算方式是不一樣的，比如如果是數字，我們想通過排序得出的結果肯定是從大到小排列，或從從小到到排列，但如果字段的數據類型被設成了文本型，它就只會按照文本的排序方式進行，像1後面就會是10而不是2。
（注：並不一定就是越小的數據類型效率越高，也存在例外，在Access中運算效率最高的數據類型是整型、長整型、貨幣型，這幾種由於在應用中使用的頻率最高，計算機系統中都對它們做過優化，所以反而比更小的字節型數據運算效率高）
8、表只應該用來存儲數據，而不應該用來輸入或編輯數據。除非是在開發階段，否則所有的數據編輯工作都應該在窗體中進行。在開發完成後，不光是表，其它的Access數據庫對象都不應該直接向最終用戶顯露展示，所有的操作都應該通過窗體來進行交互完成。
