目的： 有效的儲存，高效的訪問。1.減少資料冗餘
2.避免資料異常
3.節約儲存空間
4.高效的資料訪問
1.需求分析
2.邏輯設計er建模
3.物理設計（mysql、oracle、sql server）
4.維護優化（新需求建表、索引優化、大表拆分）
搞清楚實體與實體之間的關係？
實體包含哪些屬性？
實體的唯一標識是什麼？
對於日誌類的實體，可以進行分庫分表設計，定期歸檔。
電商例項，使用者模組、商品模組、訂單模組、購物車模組、**商模組。
可選唯一標識，使用者名稱、身份證、**、郵箱。
儲存特點，隨系統上線逐漸增加，需要永久儲存。
商品模組，包含屬性：商品編碼、商品名稱、商品描述、商品分類、**商名稱、**
可選唯一標識（商品編碼）、（商品名稱、**商名稱）
儲存特點：對於下線商品可以歸檔儲存（不要刪除）。
可用唯一標識，訂單號。
儲存特點：永久儲存（分庫分表）
購物車模組，包括屬性：使用者名稱、商品編號、商品名稱、商品**，商品分類，加入時間，商品數量...
可選唯一標識：（使用者名稱、商品編號、加入時間）、（購物車編號）
儲存特點：不用永久儲存（設定歸檔，清理規則）
可選唯一標識：**商編號、營業執照號
儲存特點：永久儲存。
矩形表示實體集
菱形表示聯絡集
橢圓表示實體屬性
線段連線屬性與實體，實體與聯絡集
遵循一二三正規化就基本夠用了，遵循它可以有效的避免資料庫操作異常及資料冗餘。
第一正規化（1nf），字段不可拆分。表中的每個欄位都是最小的資料單元
下面的設計就不符合第一正規化。
第二正規化（2nf）要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成乙個新的實體，新實體與原實體之間是一對多的關係。在 1nf 的基礎上，表中所有的非碼屬性必須【完全依賴】於候選碼，不可以部分依賴
存在部分依賴主屬性。
商品**與重量，有效期，分類，依賴於商品。
**商**，依賴於**商名稱。
拆分成3個表。商品表，**商表，**商與商品關聯表。
或者拆分成2個表。商品表，**商表。商品表關聯**商表。
第三正規化（3nf），就是不能重複儲存相同的資訊。在 2nf 的基礎上，非主屬性之間沒有相互依賴（消除傳遞依賴）
分類描述與分類存在傳遞依賴。
拆分成商品表，分類表。通過分類id來關聯分類。
bc正規化（bcnf）復合關鍵字之間也不能存在函式依賴關係
拆成**商，**商聯絡人
商品id、**商聯絡人，商品數量
選擇合適的資料庫管理系統，mysql 、oracle、sql server。
建立資料庫、表以及命名規範。
根據所選的dbms，選擇合適的字段型別。
反正規化化設計，冗餘，以空間換時間。
尊徐可讀原則、表意原則、長名原則。下面的表命名就不可取。
對於日期，優先，int，datetime，char ，varchar。
避免使用外來鍵約束，影響高併發。（降低匯入效率，增加維護成本）。
避免使用觸發器（可能出現資料異常，業務邏輯變複雜）。
反正規化，以空間換時間，適用於高併發專案。
減少表關聯數量
增加讀取效率
反正規化化要適度適量
維護資料字典（特別是狀態字段），增加備註
維護索引（增加索引，優化索引）
表結構優化
水平拆分，垂直拆分表
經常查的放在乙個表中。不常用，大字段的放到另一張表。（垂直拆分），解決表寬度大問題。
通過hash來實現水平拆分。解決資料量大問題。
具體的設計，還要根據業務進行分析。盡量設計出合適的表。好的底層，才能蓋出牢固的大樓。後期維護的時候，也盡量遵守設計步驟和原則。讓系統有條不紊的提公升。
SQL那些事兒（六） 資料庫三大正規化
通俗描述 描述乙個學生的關係，可以有學號 sno 姓名 sname 系名 sdept 等幾個屬性。由於乙個學號只對應乙個學生，乙個學生只在乙個系學習。因此當學號確定之後，姓名和該學生所在系的值也就唯一被確定了，就像自變數x確定之後，相應的函式值f x 也就唯一地被確定了一樣，稱sno函式決定snam...
資料庫設計的那些事
1，表和字段的設計規範，當然每個公司有其自己的規範 1 要有可讀性 eg studentaddress,不要設計成stuaddress 2 表意性 eg student,不要設計成ch1 3 盡量不要縮寫 eg studentaddress,不要設計成stuadd 2,字段型別的選擇 在進行資料庫資...
我和JAVA資料庫操作的那些事兒（4）
通過前面幾篇的介紹，對於jdbc的使用應該基本上夠上專案開發的要求了。但是，總是覺得還有一些問題，比如，我寫了乙個dbutil類，這個類裡持有乙個connection物件，而這個物件是被所有需要使用的地方共用的。private static connection conn null public s...