如果不能設計一個合理的數據庫模型，不僅會增加客戶端和服務器段程序的編程和維護的難度，而且將會影響系統實際運行的性能。所以，在一個系統開始實施之前，完備的數據庫模型的設計是必須的。

在一個系統分析、設計階段，因為數據量較小，負荷較低。我們往往只注意到功能的實現，而很難注意到性能的薄弱之處，等到系統投入實際運行一段時間后，才發現系統的性能在降低，這時再來考慮提高系統性能則要花費更多的人力物力，而整個系統也不可避免的形成了一個打補丁工程。

所以在考慮整個系統的流程的時候，我們必須要考慮，在高并發大數據量的訪問情況下，我們的系統會不會出現極端的情況。（例如：對外統計系統在7月16日出現的數據異常的情況，并發大數據量的的訪問造成，數據庫的響應時間不能跟上數據刷新的速度造成。具體情況是：在日期臨界時（00：00：00），判斷數據庫中是否有當前日期的記錄，沒有則插入一條當前日期的記錄。在低并發訪問的情況下，不會發生問題，但是當日期臨界時的訪問量相當大的時候，在做這一判斷的時候，會出現多次條件成立，則數據庫里會被插入多條當前日期的記錄，從而造成數據錯誤。），數據庫的模型確定下來之后，我們有必要做一個系統內數據流向圖，分析可能出現的瓶頸。

為了保證數據庫的一致性和完整性，在邏輯設計的時候往往會設計過多的表間關聯，盡可能的降低數據的冗余。（例如用戶表的地區，我們可以把地區另外存放到一個地區表中）如果數據冗余低，數據的完整性容易得到保證，提高了數據吞吐速度，保證了數據的完整性，清楚地表達數據元素之間的關系。而對于多表之間的關聯查詢（尤其是大數據表）時，其性能將會降低，同時也提高了客戶端程序的編程難度，因此，物理設計需折衷考慮，根據業務規則，確定對關聯表的數據量大小、數據項的訪問頻度，對此類數據表頻繁的關聯查詢應適當提高數據冗余設計但增加了表間連接查詢的操作，也使得程序的變得復雜，為了提高系統的響應時間，合理的數據冗余也是必要的。設計人員在設計階段應根據系統操作的類型、頻度加以均衡考慮。

另外，最好不要用自增屬性字段作為主鍵與子表關聯。不便于系統的遷移和數據恢復。對外統計系統映射關系丟失