成功的管理系統=50% 的業務+(25%的數據庫+25%的程序)
1、考察現有系統環境
大多數數據庫項目都不是從頭開始建立的，通常機構內總會存在用來滿足特定需求的現有系統。顯然，現有系統並不完美，否則你就不必再建立新系統了。但是對舊系統的研究可以讓你發現一些可能會忽略的細微問題。一般來說，考察現有系統對你絕對有好處。
2、充分預計需求的升級趨勢
詢問用戶如何看待未來需求變化非常有用，這樣做可以達到兩個目的：首先，可以清楚地了解應用設計在哪個地方應該更具靈活性以及如何避免性能瓶頸；其次，知道發生事先沒有確定的需求變更時用戶將和你一樣感到吃驚。
3、充分理解客戶的需求
看起來這應該是顯而易見的事，但需求就是來自客戶（這里要從內部和外部客戶的角度考慮）。不要依賴用戶寫下來的需求，真正的需求在客戶的腦袋里。你要讓客戶解釋其需求，而且隨着開發的繼續，還要經常詢問客戶保證其需求仍然在開發的目的之中。
一旦你認為你已經明確了業務內容，你最好同客戶進行一次系統的交流。采用客戶的術語並且向他們解釋你所想到的和你所聽到的。同時還應該用可能、將會和必須等詞匯表達出系統的關系基數。這樣你就可以讓你的客戶糾正你自己的理解。
了解業務可以在以后的開發階段節約大量的時間，而其你會發現，一旦你明確了業務需求，你就可以自己做出許多決策了。
4、確定數據對象的命名規范
一定要定義數據庫對象的命名規范，可以考慮用約定好的前綴或后綴：
對於視圖來說，可以采用vw_前綴；
對表來說，表名可以加上前綴tbl_；
對表內的列[字段]來說，數字類型可以用_N作為后綴，字符類型可以采用_C后綴等，Money類型可以采用_M后綴，日期類型可以采用_D作為后綴等等；
對於存儲過程來說，可以采用sp_前綴；
對於自定義函數，可以考慮采用udf_前綴；
此外，采用全大寫字母，且以下划線分割單詞，如：TBL_CUSTOMER_INFO
5、創建數據字典
一定要花點時間創建數據字典，其中至少應該包含每個字段的數據類型和在每個表內的主外鍵。創建數據字典確實有點費時但對其他開發人員要了解整個設計卻是完全必要的。越早創建越能有助於避免今后面臨的可能混亂，從而可以讓任何了解數據庫的人都明確如何從數據庫中獲得數據。
6、從輸入輸出下手
在定義數據庫表和字段需求（輸入）時，首先應檢查現有的或者已經設計出的報表、查詢和視圖（輸出）以決定為了支持這些輸出哪些是必要的表和字段。舉個簡單的例子：假如客戶需要一個報表按照郵政編碼排序、分段和求和，你要保證其中包括了單獨的郵政編碼字段而不要把郵政編碼糅進地址字段里。
7、報表技巧
要了解用戶通常是如何報告數據的：批處理還是在線提交報表？時間間隔是每天、每周、每月、每個季度還是每年？如果需要的話還可以考慮創建總結表。系統生成的主鍵在報表中很難管理。用戶在具有系統生成主鍵的表內用副鍵進行檢索往往會返回許多重復數據。這樣的檢索性能比較低而且容易引起混亂。
8、考慮國際化問題
在設計用到網絡或者具有其他國際特性的數據庫時，一定要記住大多數國家都有不同的字段格式，比如郵政編碼等，有些國家，比如新西蘭就沒有郵政編碼一說。
9、記錄的版本
借鑒Oracle的設計模式，每個表都設置以下6個字段：
Create_Date
Last_Modify_Date
Creator
Modifier
Modify_Number
Is_Deleted
在表中包含一個“刪除標記”字段，這樣就可以把行標記為刪除。在關系數據庫里不要單獨刪除某一行；最好采用清除數據程序而且要仔細維護索引整體性。
10、仔細選擇數據類型
在SQL中使用smallint和 tinyint類型要特別小心，比如，假如你想看看月銷售總額，你的總額字段類型是 smallint，那么，如果總額超過了$32,767你就不能進行計算操作了。
在命名字段並為其指定數據類型的時候一定要保證一致性。假如字段在某個表中叫做“agreement_number”，你就別在另一個表里把名字改成“ref1”。假如數據類型在一個表里是整數，那在另一個表里可就別變成字符型了。記住，你干完自己的活了，其他人還要用你的數據庫呢。
11、盡量避免使用觸發器
觸發器的功能通常可以用其他方式實現。在調試程序時觸發器可能成為干擾。假如你確實需要采用觸發器，你最好集中對它文檔化。
12、給文本字段留足余量
ID類型的文本字段，比如客戶ID或定單號等等都應該設置得比一般想象更大，因為時間不長你多半就會因為要添加額外的字符而難堪不已。比方說，假設你的客戶 ID為10位數長。那你應該把數據庫表字段的長度設為12或者13個字符長。這算浪費空間嗎？是有一點，但也沒你想象的那么多：一個字段加長3個字符在有1百萬條記錄，再加上一點索引的情況下才不過讓整個數據庫多占據3MB的空間。但這額外占據的空間卻無需將來重構整個數據庫就可以實現數據庫規模的增長了。身份證的號碼從15位變成18位就是最好和最慘痛的例子。
13、用約束而非商務規則強制數據完整性
如果你按照商務規則來處理需求，那么你應當檢查商務層次/用戶界面：如果商務規則以后發生變化，那么只需要進行更新即可。假如需求源於維護數據完整性的需要，那么在數據庫層面上需要施加限制條件。如果你在數據層確實采用了約束，你要保證有辦法把更新不能通過約束檢查的原因采用用戶理解的語言通知用戶界面。除非你的字段命名很冗長，否則字段名本身還不夠。
只要有可能，請采用數據庫系統實現數據的完整性。這不但包括通過標准化實現的完整性而且還包括數據的功能性。在寫數據的時候還可以增加觸發器來保證數據的正確性。不要依賴於商務層保證數據完整性；它不能保證表之間（外鍵）的完整性所以不能強加於其他完整性規則之上。
14、分布式數據系統
對分布式系統而言，在你決定是否在各個站點復制所有數據還是把數據保存在一個地方之前應該估計一下未來 5年或者 10年的數據量。當你把數據傳送到其他站點的時候，最好在數據庫字段中設置一些標記。在目的站點收到你的數據之后更新你的標記。為了進行這種數據傳輸，請寫下你自己的批處理或者調度程序以特定時間間隔運行而不要讓用戶在每天的工作后傳輸數據。本地拷貝你的維護數據，比如計算常數和利息率等，設置版本號保證數據在每個站點都完全一致。
15、強制指示完整性(參照完整性?)
沒有好辦法能在有害數據進入數據庫之后消除它，所以你應該在它進入數據庫之前將其剔除。激活數據庫系統的指示完整性特性。這樣可以保持數據的清潔而能迫使開發人員投入更多的時間處理錯誤條件。
16、關系
如果兩個實體之間存在多對一關系，而且還有可能轉化為多對多關系，那么你最好一開始就設置成多對多關系。從現有的多對一關系轉變為多對多關系比一開始就是多對多關系要難得多。
17、采用視圖
為了在你的數據庫和你的應用程序代碼之間提供另一層抽象，你可以為你的應用程序建立專門的視圖而不必非要應用程序直接訪問數據表。這樣做還等於在處理數據庫變更時給你提供了更多的自由。
18、別忘了索引
索引是從數據庫中獲取數據的最高效方式之一。95%的數據庫性能問題都可以采用索引技術得到解決。作為一條規則，我通常對邏輯主鍵使用唯一的成組索引，對系統鍵（作為存儲過程）采用唯一的非成組索引，對任何外鍵列[字段]采用非成組索引。不過，索引就象是鹽，太多了菜就咸了。你得考慮數據庫的空間有多大，表如何進行訪問，還有這些訪問是否主要用作讀寫。
大多數數據庫都索引自動創建的主鍵字段，但是可別忘了索引外鍵，它們也是經常使用的鍵，比如運行查詢顯示主表和所有關聯表的某條記錄就用得上。還有，不要索引 memo/note字段，不要索引大型字段（有很多字符），這樣作會讓索引占用太多的存儲空間。
19、用存儲過程讓系統做重活
解決了許多麻煩來產生一個具有高度完整性的數據庫解決方案之后，我決定封裝一些關聯表的功能組，提供一整套常規的存儲過程來訪問各組以便加快速度和簡化客戶程序代碼的開發。數據庫不只是一個存放數據的地方，它也是簡化編碼之地。
20、使用系統生成的主鍵
假如你總是在設計數據庫的時候采用系統生成的鍵作為主鍵，那么你實際控制了數據庫的索引完整性。這樣，數據庫和非人工機制就有效地控制了對存儲數據中每一行的訪問。采用系統生成鍵作為主鍵還有一個優點：當你擁有一致的鍵結構時，找到邏輯缺陷很容易。