幾種數據庫設計思想

四種高效數據庫設計思想——提高查詢效率：設計數據庫表結構時，我們首先要按照數據庫的三大範式進行建立數據。
1. 1NF每列不可拆分
2. 2NF確保每個表只做一件事情
3. 3NF滿足2NF，消除表中的依賴傳遞。
三大範式的出現是在上世紀70年代，由於內存資源比較昂貴，所以嚴格按照三大範式進行數據庫設計。而如今內存變得越來越廉價，在考慮效率和內存的基礎上我們可以做出最優選擇以達到最高效率。建立數據庫先按照三大範式進行建立，如果出現由於業務邏輯查詢而造成效率低的現象，可以違反三大範式進行修改數據庫。總之，效率第一。

分散計算：
分散計算的優缺點：

缺點：代碼量太大、維護困難。
優點：提高運行效率、查詢速度快、提高了數據的檢索效率。

什麼情況下使用分散計算

合同和貨物是一對多的關係，貨物和附件是一對多的關係。如果按照傳統的方式獲得某個合同的總金額：那麼我們需要從查詢合同———合同下的貨物——貨物下的附件。從頁面進行計算：合同金額=貨物單價數量+附件單價數量 （每個貨物的總金額計算出來+每個貨物下所有附件的總金額計算出來 然後加到一起構成合同的總金額）這樣頁面上上的數據計算量是非常龐大的，所以就會造成用戶少的時候頁面加載速度還可以，用戶量一旦多起來就會造成頁面加載很慢，用戶不願等待的現象出現。

措施：

合同、貨物、附件中分別加入總金額的冗餘字段：可以在平時添加貨物時，添加附件時，分別計算出貨物總金額，附件總金額，加到數據庫中，在更新購銷合同金額。這樣就相當於將一次更新的工作量分散到平時的多次計算過程中，所以查詢購銷合同總金額的速度就會很快。從數據庫查詢，遠比從頁面計算效率要高N多倍。

打斷設計思想：
當關聯查詢的層級大於4層時，就要考慮打斷設計，這樣可以藉助跳躍查詢實現查詢速度翻倍。
就是在傳統的一對多關係中，都會在多方加入一個一方的主鍵作爲外鍵，但在是在打斷設計思想的指導下，不會這樣實現，它會在一的一方加入一個冗餘字段，用於保存多的一方的主鍵，並且指定分隔符進行分隔。雖然多的一方沒有加入一的一方的主鍵做外鍵，但仍保持了原有的一對多關係。
真正的實現原理：就是通過打段字段，實現數據的冗餘，從而一樣的可以解決一個報運單下多個購銷合同的問題。1.傳統做法：

出口報運單對象——加載出購銷合同的集合——遍歷出每個購銷合同——通過購銷合同得到貨物——再通過貨物得到附件。

2.打段設計基礎上的做法：

出口報運單——得到它的一個字段（購銷合同id形成的集合）——直接到貨物表中進行查詢（from ContractProduct cp where cp.contract.id in(購銷合同id形式的集合)）

打斷設計+跳躍查詢做法：
按照傳統設計方法：

財務如果想知道這筆款項從哪個貨物附件是從哪個生產廠家生產的：一個環節套一個環節，不可跳躍。一對一對應關係，通過對象導航得用很多HQL語句才能夠導到廠家信息。關聯7級才能找到目標對象。加載速度一定很慢！

打斷設計+跳躍查詢做法應用

跳躍查詢

跳躍查詢的前提：提前採用打斷設計表的優化，而打斷設計思想的關鍵是字段的冗餘，就是在報運單中加入一個冗餘字段嗎，放入購銷合同的id集合。

財務人員得到財務報運單ID——裝箱單（Export_IDS）——報運單（Export_ID in(Export_IDS)）——跳躍查詢直接查詢貨物（from CONTRACT_PRODUCT WHERE CONTRACT_PRODUCT_ID IN (購銷合同裏面合同編號的集合（正好是用逗號隔開的一堆值即CONTRACT_IDS的值）)）——貨物裏本身就有廠家的廠家名信息等。操作完成！
三次查詢就可以拿到最終結果。

數據搬家：
數據搬家也是數據庫優化的一種：表級別的數據冗餘，再添加一個出口報運單時，就能得到這個報運單所報運的貨物和附件，如何實現報運單下貨物和附件的數據，實現原理就是首先找到購銷合同對象，再得到購銷合同下的貨物和附件，針對貨物和附件分別進行數據拷貝。
應用：
傳統：通過商品明細——貨號——查詢貨物對象——對象導航得到附件
數據搬家：商品明細對象導航——附件信息
之前查三次,現在查兩次就可以得到報運商品的信息。
冗餘沒問題，效率第一位。

小結：
以上四種方式均違反了數據庫的三大範式，採用了數據冗餘方式，小編不是主張大家採用數據冗餘，而是在三大範式和查詢效率發生衝突的情況下，我們採用違法三大範式，選擇效率優先原則！這四種方式，是我工作中用到的，效率較高的四中方式，與大家分享！