前言

 在設計關系型數據庫時，我們從課上的學習得知，需要參照不同的范式及原則，設計表結構與表關系。在課上，我們關注的角度更多是，設計要符合范式，保證數據不冗余。但在實際的開發設計中，我們往往要從更多角度思考數據庫的設計原則，根據不同的需求場景，進行不同角度的側重。比如開發是否便捷，表結構是否易維護，查詢效率是否達到要求等等。

設計原則

一般的企業級應用數據庫中，對于數據的冗余是有一定容忍性的，但對于數據庫增刪改查的效率，往往會有很高的要求。這時候，我們之前遵循的一些原則，就要做出不同程度的改變。比如，之前依據少冗余原則，參考的設計三大范式，可能在數據庫增刪改查效率的面前，就要做一些妥協了。

在設計能容忍冗余、重視效率的數據庫時，個人認為，主要需要考慮以下幾方面：

1、每個表增刪改的范圍盡量都在本表進行

這條原則也是與三大范式有些相悖的，但這樣做的好處非常明顯。

第一，還是從開銷角度出發，這樣做的話，增刪改的開銷通常比多表要低。

第二，這樣便捷開發，在數據存儲過程中，如果涉及多表操作，表越多，處理業務邏輯的代碼就越多，在開發時難度也就越大。

第三，可維護性高，這一點和第二點有點重合，但就是因為單表設計的業務代碼會相對簡單，所以日后的維護也會相對容易，反之，多表的業務代碼龐雜，日后的維護也會非常的困難。

2、通過主鍵體現對應關系，且應體現流程順序

企業級應用最大的難題就是梳理業務，理清業務模塊之間的對應關系。在數據庫中，表中包含的主鍵除了要體現對應關系外，還應該體現生成順序或流程順序的邏輯。

3、每個表盡量代表一個業務模塊，盡量記錄模塊中的所有字段

由第一個原則推理出這個原則，因為在本表增刪改查的開銷小，所以，如果一個表足夠的內聚，那么這個表就要盡量記錄模塊中的所有字段。

tips：

如果之后業務模塊內字段過多，可以進行分表處理，但如果一開始就是分開設計的，那么處理會很麻煩。

4、中間表不可以隨意使用

在充分遵循三大范式的前提下，我們的設計就會有很多的中間表(關系表)。但如果在兩個表中，其中有一個表增刪改頻繁，那么從效率角度而言，這樣的設計就是不合格的。這樣的設計確實會減少很多數據冗余，但是也會大大增加每條數據增刪改的開銷。所以從一般的企業級應用場景來看，中間表不可以隨意使用。

通過了解中間表的使用缺陷，我們也就知道了什么時候可以使用中間表。當左表和右表都沒有非常頻繁的改動需求，但有非常頻繁的聯表查詢需求的時，我們就可以運用中間表，來提升查詢效率，并減少數據冗余。

總結

經過了幾次設計我發現一個大道理哈哈，其實技術最后還是要為具體的業務場景服務。很多計算機問題都是需要時間和空間的開銷相互妥協，在具體的業務場景中，往往也是如此。三大范式只是一般設計數據庫的基本理念，通過三大范式，我們可以建立一個小冗余、表結構合理的數據庫，但就像之前說的，表結構合理不代表符合業務需求，如有特殊業務情況，就要按特殊情況對待。

一般而言，需求 > 性能 > 表結構(冗余)。