如果不能設計乙個合理的資料庫模型，不僅會增加客戶端和伺服器段程式的程式設計和維護的難度，而且將會影響系統實際執行的效能。所以，在乙個系統開始實施之前，完備的資料庫模型的設計是必須的。
在乙個系統分析、設計階段，因為資料量較小，負荷較低，我們往往只注意到功能的實現，而很難注意到效能的薄弱之處，等到系統投入實際執行一段時間後，才發現系統的效能在降低，這時再來考慮提高系統效能則要花費更多的人力物力，而整個系統也不可避免的形成了乙個打補丁工程。所以在考慮整個系統的流程的時候，我們必須要考慮，在高併發大資料量的訪問情況下，我們的系統會不會出現極端的情況。（例如：對外統計系統在7月16日出現的資料異常的情況，併發大資料量的的訪問造成，資料庫的響應時間不能跟上資料重新整理的速度造成。具體情況是：在日期臨界時（00：00：00），判斷資料庫中是否有當前日期的記錄，沒有則插入一條當前日期的記錄。在低併發訪問的情況下，不會發生問題，但是當日期臨界時的訪問量相當大的時候，在做這一判斷的時候，會出現多次條件成立，則資料庫裡會被插入多條當前日期的記錄，從而造成資料錯誤）。資料庫的模型確定下來之後，我們有必要做乙個系統內資料流向圖，分析可能出現的瓶頸。
為了保證資料庫的一致性和完整性，在邏輯設計的時候往往會設計過多的表間關聯，盡可能的降低資料的冗餘。（例如使用者表的地區，我們可以把地區另外存放到乙個地區表中）如果資料冗餘低，資料的完整性容易得到保證，提高了資料吞吐速度，保證了資料的完整性，清楚地表達資料元素之間的關係。而對於多表之間的關聯查詢（尤其是大資料表）時，其效能將會降低，同時也提高了客戶端程式的程式設計難度，因此，
物理設計需折衷考慮，根據業務規則，確定對關聯表的資料量大小、資料項的訪問頻度，對此類資料表頻繁的關聯查詢應適當提高資料冗餘設計但增加了表間連線查詢的操作，也使得程式的變得複雜，為了提高系統的響應時間，合理的資料冗餘也是必要的。
設計人員在設計階段應根據系統操作的型別、 頻度加以均衡考慮。
另外，最好不要用自增屬性字段作為主鍵與子表關聯
。不便於系統的遷移和資料恢復。
原來的**必須可以通過由它分離出去的**重新構建
。使用這個規定的好處是，你可以確保不會在分離的**中引入多餘的列，所有你建立的**結構都與它們的實際需要一樣大。應用這條規定是乙個好習慣，不過除非你要處理乙個非常大型的資料，否則你將不需要用到它。（例如乙個通行證系統，我可以將userid，username，userpassword，單獨出來作個表， 再把userid作為其他表的外來鍵）
表的設計具體注意的問題：1、
資料行的長度不要超過8020位元組，如果超過這個長度的話在物理頁中這條資料會占用兩行從而造成儲存碎片，降低查詢效率。 2
、能夠用數字型別的字段盡量選擇數字型別而不用字串型別的
（**號碼），這會降低查詢和連線的效能，並會增加儲存開銷。這是因為引擎在處理查詢和連線回逐個比較字串中每乙個字元，而對於數字型而言只需要比較一次就夠了。 3
、對於不可變字元型別char和可變字元型別varchar 都是8000位元組,char查詢快，但是耗儲存空間，varchar查詢相對慢一些但是節省儲存空間。在設計欄位的時候可以靈活選擇4、
欄位的長度在最大限度的滿足可能的需要的前提下，應該盡可能的設得短一些
，這樣可以提高查詢的效率，而且在建立索引的時候也可以減少資源的消耗。
資料庫設計文件結構
本章節主要是對系統的背景和需要要完成的主要功能的大體介紹。需求分析就是分析使用者的要求。通過詳細調查現實世界要處理的物件 組織，部門，企業等 充分了解原系統的工作概況，明確使用者的各種需求，然後在此基礎上確定新系統的功能。新系統必須充分考慮今後可能的擴充和改變，不能僅僅按當前應用需求來設計資料庫。把...
資料庫設計樹形結構的技巧
前言 當業務中遇到樹形結構時，比如選單，省市區，部門等時如何設計資料庫。一種設計可以通過每個字段帶有parent id 來遞迴獲取所有的節點 也可以通過另一種方法來獲取某個節點的子節點 使用level記錄當前節點的父節點code 新增乙個輔助的varchar欄位level，欄位的邏輯是多個部門的id...
資料庫結構設計
1.3概念設計的任務 1.2概念設計的依據 需求分析的文件，需求說明書，功能模型 資料流圖或idef0圖 資訊模型 er圖 和資料庫概念說明書是資料庫邏輯設計的依據 1.2 資料庫概念設計過程 1.3 資料建模方法 er建模方法 idef1x建模方法標識er模型中的聯絡，依次轉換與每個聯絡相關聯的實...