設計數據庫須要考慮到的問題

成功的管理系統=50% 的業務+(25%的數據庫+25%的程序)

一、考察現有系統環境
    大多數數據庫項目都不是從頭開始創建的，一般機構內總會存在用來知足特定需求的現有系統。顯然，現有系統並不完美，不然你就沒必要再創建新系統了。可是對舊系統的研究可讓你發現一些可能會忽略的細微問題。通常來講，考察現有系統對你絕對有好處。

二、充分預計需求的升級趨勢
    詢問用戶如何看待將來需求變化很是有用，這樣作能夠達到兩個目的：首先，能夠清楚地瞭解應用設計在哪一個地方應該更具靈活性以及如何避免性能瓶頸；其次，知道發生事先沒有肯定的需求變動時用戶將和你同樣感到吃驚。

三、充分理解客戶的需求
       看起來這應該是顯而易見的事，但需求就是來自客戶（這裏要從內部和外部客戶的角度考慮）。不要依賴用戶寫下來的需求，真正的需求在客戶的腦殼裏。你要讓客戶解釋其需求，並且隨着開發的繼續，還要常常詢問客戶保證其需求仍然在開發的目的之中。
    一旦你認爲你已經明確了業務內容，你最好同客戶進行一次系統的交流。採用客戶的術語而且向他們解釋你所想到的和你所聽到的。同時還應該用可能、將會和必須等詞彙表達出系統的關係基數。這樣你就可讓你的客戶糾正你本身的理解。
    瞭解業務能夠在之後的開發階段節約大量的時間，而其你會發現，一旦你明確了業務需求，你就能夠本身作出許多決策了。

四、肯定數據對象的命名規範
    必定要定義數據庫對象的命名規範，能夠考慮用約定好的前綴或後綴：
對於視圖來講，能夠採用vw_前綴；
對錶來講，表名能夠加上前綴tbl_；
對錶內的列[字段]來講，數字類型能夠用_N做爲後綴，字符類型能夠採用_C後綴等，Money類型能夠採用_M後綴，日期類型能夠採用_D做爲後綴等等；
對於存儲過程來講，能夠採用sp_前綴；
對於自定義函數，能夠考慮採用udf_前綴；
此外，採用全大寫字母，且如下劃線分割單詞，如：TBL_CUSTOMER_INFO

五、建立數據字典
    必定要花點時間建立數據字典，其中至少應該包含每一個字段的數據類型和在每一個表內的主外鍵。建立數據字典確實有點費時但對其餘開發人員要了解整個設計倒是徹底必要的。越早建立越能有助於避免從此面臨的可能混亂，從而可讓任何瞭解數據庫的人都明確如何從數據庫中得到數據。
 
六、從輸入輸出下手
    在定義數據庫表和字段需求（輸入）時，首先應檢查現有的或者已經設計出的報表、查詢和視圖（輸出）以決定爲了支持這些輸出哪些是必要的表和字段。舉個簡單的例子：假如客戶須要一個報表按照郵政編碼排序、分段和求和，你要保證其中包括了單獨的郵政編碼字段而不要把郵政編碼糅進地址字段裏。

七、報表技巧
    要了解用戶一般是如何報告數據的：批處理仍是在線提交報表？時間間隔是天天、每週、每個月、每一個季度仍是每一年？若是須要的話還能夠考慮建立總結表。系統生成的主鍵在報表中很難管理。用戶在具備系統生成主鍵的表內用副鍵進行檢索每每會返回許多重複數據。這樣的檢索性能比較低並且容易引發混亂。

八、考慮國際化問題
    在設計用到網絡或者具備其餘國際特性的數據庫時，必定要記住大多數國家都有不一樣的字段格式，好比郵政編碼等，有些國家，好比新西蘭就沒有郵政編碼一說。

九、記錄的版本
    借鑑Oracle的設計模式，每一個表都設置如下6個字段：
    Create_Date
    Last_Modify_Date
    Creator
    Modifier
    Modify_Number
    Is_Deleted
在表中包含一個「刪除標記」字段，這樣就能夠把行標記爲刪除。在關係數據庫裏不要單獨刪除某一行；最好採用清除數據程序並且要仔細維護索引總體性。
 
十、仔細選擇數據類型
    在SQL中使用smallint和 tinyint類型要特別當心，好比，假如你想看看月銷售總額，你的總額字段類型是 smallint，那麼，若是總額超過了$32,767你就不能進行計算操做了。
    在命名字段併爲其指定數據類型的時候必定要保證一致性。假如字段在某個表中叫作「agreement_number」，你就別在另外一個表裏把名字改爲「ref1」。假如數據類型在一個表裏是整數，那在另外一個表裏可就別變成字符型了。記住，你幹完本身的活了，其餘人還要用你的數據庫呢。
 
十一、儘可能避免使用觸發器
    觸發器的功能一般能夠用其餘方式實現。在調試程序時觸發器可能成爲干擾。假如你確實須要採用觸發器，你最好集中對它文檔化。

十二、給文本字段留足餘量
    ID類型的文本字段，好比客戶ID或定單號等等都應該設置得比通常想象更大，由於時間不長你多半就會由於要添加額外的字符而難堪不已。比方說，假設你的客戶 ID爲10位數長。那你應該把數據庫表字段的長度設爲12或者13個字符長。這算浪費空間嗎？是有一點，但也沒你想象的那麼多：一個字段加長3個字符在有1百萬條記錄，再加上一點索引的狀況下才不過讓整個數據庫多佔據3MB的空間。但這額外佔據的空間卻無需未來重構整個數據庫就能夠實現數據庫規模的增加了。身份證的號碼從15位變成18位就是最好和最慘痛的例子。

1三、用約束而非商務規則強制數據完整性
    若是你按照商務規則來處理需求，那麼你應當檢查商務層次/用戶界面：若是商務規則之後發生變化，那麼只須要進行更新便可。假如需求源於維護數據完整性的須要，那麼在數據庫層面上須要施加限制條件。若是你在數據層確實採用了約束，你要保證有辦法把更新不能經過約束檢查的緣由採用用戶理解的語言通知用戶界面。除非你的字段命名很冗長，不然字段名自己還不夠。
    只要有可能，請採用數據庫系統實現數據的完整性。這不但包括經過標準化實現的完整性並且還包括數據的功能性。在寫數據的時候還能夠增長觸發器來保證數據的正確性。不要依賴於商務層保證數據完整性；它不能保證表之間（外鍵）的完整性因此不能強加於其餘完整性規則之上。

1四、分佈式數據系統
    對分佈式系統而言，在你決定是否在各個站點複製全部數據仍是把數據保存在一個地方以前應該估計一下將來 5年或者 10年的數據量。當你把數據傳送到其餘站點的時候，最好在數據庫字段中設置一些標記。在目的站點收到你的數據以後更新你的標記。爲了進行這種數據傳輸，請寫下你本身的批處理或者調度程序以特定時間間隔運行而不要讓用戶在天天的工做後傳輸數據。本地拷貝你的維護數據，好比計算常數和利息率等，設置版本號保證數據在每一個站點都徹底一致。

1五、強制指示完整性(參照完整性?)
    沒有好辦法能在有害數據進入數據庫以後消除它，因此你應該在它進入數據庫以前將其剔除。激活數據庫系統的指示完整性特性。這樣能夠保持數據的清潔而能迫使開發人員投入更多的時間處理錯誤條件。

1六、關係
    若是兩個實體之間存在多對一關係，並且還有可能轉化爲多對多關係，那麼你最好一開始就設置成多對多關係。從現有的多對一關係轉變爲多對多關係比一開始就是多對多關係要可貴多。

1七、採用視圖
    爲了在你的數據庫和你的應用程序代碼之間提供另外一層抽象，你能夠爲你的應用程序創建專門的視圖而沒必要非要應用程序直接訪問數據表。這樣作還等於在處理數據庫變動時給你提供了更多的自由。

1八、別忘了索引
    索引是從數據庫中獲取數據的最高效方式之一。95%的數據庫性能問題均可以採用索引技術獲得解決。做爲一條規則，我一般對邏輯主鍵使用惟一的成組索引，對系統鍵（做爲存儲過程）採用惟一的非成組索引，對任何外鍵列[字段]採用非成組索引。不過，索引就象是鹽，太多了菜就鹹了。你得考慮數據庫的空間有多大，表如何進行訪問，還有這些訪問是否主要用做讀寫。
    大多數數據庫都索引自動建立的主鍵字段，可是可別忘了索引外鍵，它們也是常用的鍵，好比運行查詢顯示主表和全部關聯表的某條記錄就用得上。還有，不要索引 memo/note字段，不要索引大型字段（有不少字符），這樣做會讓索引佔用太多的存儲空間。

1九、用存儲過程讓系統作重活
    解決了許多麻煩來產生一個具備高度完整性的數據庫解決方案以後，我決定封裝一些關聯表的功能組，提供一整套常規的存儲過程來訪問各組以便加快速度和簡化客戶程序代碼的開發。數據庫不僅是一個存放數據的地方，它也是簡化編碼之地。
 
20、使用系統生成的主鍵    假如你老是在設計數據庫的時候採用系統生成的鍵做爲主鍵，那麼你實際控制了數據庫的索引完整性。這樣，數據庫和非人工機制就有效地控制了對存儲數據中每一行的訪問。採用系統生成鍵做爲主鍵還有一個優勢：當你擁有一致的鍵結構時，找到邏輯缺陷很容易。