因為不夠詳細的設計文件很可能讓設計人員的電話打爆，讓開發人員瞎蒙某些欄位的含義。

下面我們以物理設計文件為例，討論如何書寫詳盡的資料庫文件。

1、基本的設計需要。如表的定義，表中各個欄位的定義等等。這也是我們最常見的資料庫物理設計文件。(咱剛開始做資料庫物理設計就提供這樣的文件，哈哈)

2、擴充套件設計的需要。某些欄位的預設值、Check約束、外來鍵約束等，表的索引、觸發器、物理儲存等。

3、將資料庫中的SQL函式、儲存過程等等所有資料庫物件都新增到資料庫物理設計文件中。

4、資料庫訪問許可權。很多設計師都會遺漏這一塊內容。對於簡單的系統由DBA去建立資料庫的時候分配許可權即可，而複雜的系統(很多個數據庫使用者)最好還是將資料庫的許可權寫進文件，統一設計維護。

注：以上幾點確保僅靠一份資料庫物理設計文件就能產生一個物理資料庫，而不需要做其它物理資料庫的DDL或DML操作。

5、每個資料庫物件的用途註釋、取值註釋(如性別欄位的取值註釋)等等。這個步驟很多設計師都不願意或者乾脆省略掉。其實時間一久，人的記憶力是不可靠的。更重要的是設計師離職等因素將導致整個系統的可維護性急劇降低，後續設計師可能一換再換，開發人員一跑再跑。

6、由資料庫內容來維護設計文件。很多公司，很多時候，國內資料庫設計師的地位並沒有想象中的那麼高(除了兼做資料庫設計的專案經理/主管)，開發人員很可能會自己新增某些表的索引，增加儲存過程、增加函式等，他們最多就是通知一聲設計師說我加了個某某東西。這時候設計師如果不跟進，將新加的東西增加到設計文件中，日子一久，原來的資料庫物理設計文件將變得毫無意義，而且可能會讓人誤入歧途。因此沒有進行維護工作的設計文件很可能就是一份形式主義報告。