1. 考察現有環境
在設計一個新數據庫時，你不但應該仔細研究業務需求而且還要考察現有的系統。大多數數據庫項目都不是從頭開始建立的；通常，機構內總會存在用來滿足特定需求的現有系統（可能沒有實現自動計算）。顯然，現有系統並不完美，否則你就不必再建立新系統了。但是對舊系統的研究可以讓你發現一些可能會忽略的細微問題。一般來說，考察現有系統對你絕對有好處。
2. 定義標準的對象命名規範
一定要定義數據庫對象的命名規範。對數據庫表來說，從項目一開始就要確定表名是採用複數還是單數形式。此外還要給表的別名定義簡單規則（比方說，如果表名是一個單詞，別名就取單詞的前 4 個字母；如果表名是兩個單詞，就各取兩個單詞的前兩個字母組成 4 個字母長的別名；如果表的名字由 3 個單詞組成，你不妨從頭兩個單詞中各取一個然後從最後一個單詞中再取出兩個字母，結果還是組成 4
字母長的別名，其餘依次類推）對工作用表來說，表名可以加上前綴 WORK_
後面附上採用該表的應用程序的名字。表內的列[字段]要針對鍵採用一整套設計規則。比如，如果鍵是數字類型，你可以用 _N 作為後綴；如果是字符類型則可以採用 _C 後綴。對列[字段]名應該採用標準的前綴和後綴。再如，假如你的表裡有好多「money」字段，你不妨給每個列[字段]增加一個 _M 後綴。還有，日期列[字段]最好以 D_ 作為名字打頭。
檢查表名、報表名和查詢名之間的命名規範。你可能會很快就被這些不同的數據庫要素的名稱搞糊塗了。假如你堅持統一地命名這些數據庫的不同組成部分，至少你應該在這些對像名字的開頭用 Table、Query 或者 Report 等前綴加以區別。
如果採用了 Microsoft Access，你可以用 qry、rpt、tbl 和 mod 等符號來標識對像（比如 tbl_Employees）。我在和 SQL Server 打交道的時候還用過 tbl 來索引表，但我用 sp_company （現在用sp_feft_）標識存儲過程，因為在有的時候如果我發現了更好的處理辦法往往會保存好幾個拷貝。我在實現 SQL Server 2000
時用 udf_ （或者類似的標記）標識我編寫的函數。
3. 工欲利其器
採用理想的數據庫設計工具，比如：SyBase 公司的 PowerDesign，她支持 PB、VB、Delphe 等語言，通過 ODBC
可以連接市面上流行的 30 多個數據庫，包括 dBase、FoxPro、VFP、SQL Server 等，今後有機會我將著重介紹
PowerDesign 的使用。
4. 獲取數據模式資源手冊
正在尋求示例模式的人可以閱讀《數據模式資源手冊》一書，該書由 Len Silverston、W. H. Inmon 和 Kent
Graziano 編寫，是一本值得擁有的最佳數據建模圖書。該書包括的章節涵蓋多種數據領域，比如人員、機構和工作效能等。
5. 暢想未來，但不可忘了過去的教訓
我發現詢問用戶如何看待未來需求變化非常有用。這樣做可以達到兩個目的：首先，你可以清楚地瞭解應用設計在哪個地方應該更具靈活性以及如何避免性能瓶頸；其次，你知道發生事先沒有確定的需求變更時用戶將和你一樣感到吃驚。
一定要記住過去的經驗教訓！我們開發人員還應該通過分享自己的體會和經驗互相幫助。即使用戶認為他們再也不需要什麼支持了，我們也應該對他們進行這方面的教育，我們都曾經面臨過這樣的時刻「當初要是這麼做了該多好..」。
6. 在物理實踐之前進行邏輯設計
在深入物理設計之前要先進行邏輯設計。隨著大量的 CASE
工具不斷湧現出來，你的設計也可以達到相當高的邏輯水準，你通常可以從整體上更好地瞭解數據庫設計所需要的方方面面。