以下描述僅僅是個人經驗總結，僅供參考！！！
我認為資料庫設計分為庫和表的設計，所以從這兩方面著手介紹。
庫的設計
1、資料庫名稱要明確，可以加字首或字尾的方式，使其看起來有業務含義，比如資料庫名稱可以為business_db(業務資料庫）。
2、在乙個企業中，如果依賴很多產品，但是每個產品都使用同一套使用者，那麼應該將使用者單獨構建乙個庫，叫做企業使用者中心。
3、不同型別的資料應該分開管理，例如，財務資料庫，業務資料庫等。
4、盡可能少的使用業務邏輯，由於儲存過程在不同的資料庫中，支援方式不一樣，因此不建議過多使用和使用複雜的儲存過程。為資料庫伺服器降低壓力，不要讓資料庫處理過多的業務邏輯，將業務邏輯處理放到應用程式中。
表設計資料庫表命名，將業務和基礎表區分，採用駝峰表示法見文知意等。
資料不要物理刪除，應該做邏輯刪除，加乙個標誌位，以防使用者後悔時，能夠恢復 。
新增時間，有新增時間可以明確知道記錄什麼時候新增的
修改時間，可以知道記錄什麼時候被修改了，一旦資料出現問題，可以根據修改時間來定位問題。比如某人在這個時間做了哪些事。
基本表及其字段之間的關係, 應盡量滿足第三正規化。但是，滿足第三正規化的資料庫設計，往往不是 最好的設計。為了提高資料庫的執行效率，常常需要降低正規化標準：適當增加冗餘，達到以空間換時間 的目的
若兩個實體之間存在多對多的關係，則應消除這種關係。對資料庫的查詢都要進行磁碟的讀寫，多對多要通過三張表的查詢，每張表的開啟關閉要耗時間的，如果把它拆分為一對多的關係，就相當於減少了一張表，速度會提快。消除的辦法是，在兩者之間增加第三個實體。這樣，原來乙個多對多的關係，現在變為兩個一對多的關係。要將原來兩個實體的屬性合理地分配 到三個實體中去
對於主鍵的設計：
不建議用多個字段做主鍵，單個表還可以，但是關聯關係就會有問題，主鍵自增是高效能的。匯入匯出就有問題
一般情況下，如果有兩個外來鍵，不建議採用兩個外來鍵作為聯合主鍵，刪除記錄的時候有可能刪除多了。另建乙個字段作為主鍵。除非這條記錄沒有邏輯刪除標誌，且該錶永遠只有一條此聯合主鍵的記錄。
一般而言，乙個實體不能既無主鍵又無外來鍵，至少有個主鍵。在e—r 圖中, 處於葉子部位的實體, 可以定義主鍵，也可以不定義主鍵(因為它無子孫), 但必須要有外來鍵(因為它有父親)。
2013 3 27工作中關於資料庫設計的
關於未加密密碼欄位的建議 客戶端傳送過來的資料，尤其是密碼都要經過加密處理的，而加密又是一向不可逆的過程，在更改密碼時候，如果傳送到後台php 程式的是加密過的資料，那麼未加密字段 password 就顯得很雞肋。關於主鍵id 的建議從占用資料庫空間的角度考慮 12位隨機碼占用的資料庫空間為 6個位...
2013 3 27工作中關於資料庫設計的幾點建議
關於未加密密碼欄位的建議 客戶端傳送過來的資料，尤其是密碼都要經過加密處理的，而加密又是一向不可逆的過程，在更改密碼時候，如果傳送到後台php 程式的是加密過的資料，那麼未加密字段 password 就顯得很雞肋。關於主鍵id 的建議從占用資料庫空間的角度考慮 12位隨機碼占用的資料庫空間為 6個位...
工作中資料庫知識使用小結
1.獲取資料庫表的所有欄位的資訊 包括不同列的長度 select from information schema.columns where table name 表名 檢視表結構 desc 表名 2.查詢表中列的注釋資訊 select from information schema.columns...