5. 采用視圖
為了在你的數據庫和你的應用程序代碼之間提供另一層抽象，你可以為你的應用程序建立專門的視圖而不必非要應用程序直接訪問數據表。這樣做還等於在處理數據庫變更時給你提供了更多的自由。
6. 給數據保有和恢復制定計劃考慮數據保有策略並包含在設計過程中，預先設計你的數據恢復過程。采用可以發布給用戶/開發人員的數據字典實現方便的數據識別同時保證對數據源文檔化。編寫在線更新來“更新查詢”供以後萬一數據丟失可以重新處理更新。
7. 用存儲過程讓系統做重活解決了許多麻煩來產生一個具有高度完整性的數據庫解決方案之後，我所在的團隊決定封裝一些關聯表的功能組，提供一整套常規的存儲過程來訪問各組以便加快速度和簡化客戶程序代碼的開發。在此期間，我們發現3GL 編碼器設置了所有可能的錯誤條件，比如以下所示：
SELECT Cnt = COUNT (*)
FROM []
WHERE [
] =
IF Cnt = 0
BEGIN
INSERT INTO []
( [< primary key column>] )
VALUES ( )
END
ELSE
BEGIN
END
而一個非3GL 編碼器是這樣做的：
INSERT INTO []
( [< primary key column>] )
VALUES
( )
IF @@ERROR = 2627 -- Literal error code for Primary Key Constraint
BEGIN
END
第2 個程序簡單多了，而且事實上，利用了我們給數據庫的功能。雖然我個人不喜歡使用嵌入文字（2627）。但是那樣可以很方便地用一點預先處理來代替。數據庫不只是一個存放數據的地方，它也是簡化編碼之地。
8. 使用查找
控制數據完整性的最佳方式就是限制用戶的選擇。只要有可能都應該提供給用戶一個清晰的價值列表供其選擇。這樣將減少鍵入代碼的錯誤和誤解同時提供數據的一致性。某些公共數據特別適合查找：國家代碼、狀態代碼等。
第5 部分— 各種小技巧
1. 文檔、文檔、文檔
對所有的快捷方式、命名規范、限制和函數都要編制文檔。
采用給表、列、觸發器等加注釋的數據庫工具。是的，這有點費事，但從長遠來看，這樣做對開發、支持和跟蹤修改非常有用。
取決於你使用的數據庫系統，可能有一些軟件會給你一些供你很快上手的文檔。你可能希望先開始在說，然後獲得越來越多的細節。或者你可能希望周期性的預排，在輸入新數據同時隨著你的進展對每一部分細節化。不管你選擇哪種方式，總要對你的數據庫文檔化，或者在數據庫自身的內部或者單獨建立文檔。這樣，當你過了一年多時間後再回過頭來做第2 個版本，你犯錯的機會將大大減少。
2. 使用常用英語（或者其他任何語言）而不要使用編碼
為什麼我們經常采用編碼（比如9935A 可能是墨水筆的供應代碼，4XF788-Q 可能是帳目編碼）？理由很多。但是用戶通常都用英語進行思考而不是編碼。工作5 年的會計或許知道4XF788-Q 是什麼東西，但新來的可就不一定了。在創建下拉菜單、列表、報表時最好按照英語名排序。假如你需要編碼，那你可以在編碼旁附上用戶知道的英語。
3. 保存常用信息
讓一個表專門存放一般數據庫信息非常有用。我常在這個表裡存放數據庫當前版本、最近檢查/修復（對Access）、關聯設計文檔的名稱、客戶等信息。這樣可以實現一種簡單機制跟蹤數據庫，當客戶抱怨他們的數據庫沒有達到希望的要求而與你聯系時，這樣做對非客戶機/服務器環境特別有用。
4. 測試、測試、反復測試
建立或者修訂數據庫之後，必須用用戶新輸入的數據測試數據字段。最重要的是，讓用戶進行測試並且同用戶一道保證你選擇的數據類型滿足商業要求。測試需要在把新數據庫投入實際服務之前完成。
5. 檢查設計
在開發期間檢查數據庫設計的常用技術是通過其所支持的應用程序原型檢查數據庫。換句話說，針對每一種最終表達數據的原型應用，保證你檢查了數據模型並且查看如何取出數據。
6. Access 設計技巧
對復雜的Microsoft Access 數據庫應用程序而言，可以把所有的主表放在一個數據庫文件裡，然後增加其他數據庫文件和裝載同原有數據庫有關的特殊函數。根據需要用這些函數連接到主文件中的主表。比如數據輸入、數據QC、統計分析、向管理層或者政府部門提供報表以及各類只讀查詢等。
這一措施簡化了用戶和組權限的分配，而且有利於應用程序函數的分組和劃分，從而在程序必須修改的時候易於管理。
