就我個人的經驗來說，資料庫雖然在設計上確實需要有一定的經驗，但是它並不是最難的。

對於資料的設計其實是對於現實中業務的一種抽象。

就我的習慣的話，我會先對於現實中的業務場景、業務的角色進行分析。

我有一個對於物料管理的倉庫，我需要對我的物料的進銷存進行管理。

那麼我們就需要分析，沒有系統的時候，人與人之間的業務是怎麼流轉的，他們都是透過哪些表單來進行流轉的，上下級之間的訊息傳遞和反饋都是怎麼進行的。

當知道了業務以後，我們的資料庫無非就是對於現實中的業務的一種具現。

例如：業務的傳遞都是在業務人員之間的，我們已經整理表單的傳遞，那角色其實就已經在這些傳遞中存在了。

但是，業務的角色是業務的角色，我們還要包括財務的角色，那對於財務來說，他需要在哪些環節看到這些業務的單據？並且需要怎麼處理？財務的處理結果又包括哪些？不同的處理結果對於下一步的操作又有什麼影響。

當我們把這一切的邏輯整理完成後，我們對於資料庫的功能上就已經滿足了。

例如：我們需要對不同的表進行一個分類，我個人喜歡把表分成三種，一種是基礎資料表，一種是過程表，一種是結果表。

怎麼解釋呢？

基礎資料表：顧名思義，就是對於基礎資料的維護，哪些可以成為基礎資料呢？就是我們的業務發生的各個過程中，這些資料都是可以參與其中的，這就是基礎資料。

例如：貨物的資訊，客戶的資訊。

過程表：就是僅僅在一個過程中使用的表，當這個過程結束了，這個表就沒用了。

例如：訂單表，付款單表。他們表示的僅僅是訂單從下單到最後關閉的這個過程，關閉以後，這個訂單表其實我們就不會再去使用它了。

例如：日誌表、賬單表。

那我們在進行資料庫設計的時候，就需要將這些使用情況考慮進去，將不同功能的表進行分離，儘量降低耦合，讓相互表的修改不會影響使用。

例如：收款單，我們需要收一筆款的時候，就會生成這個收款單，當款收到後，這個收款單的功能就結束了。

但現實的情況中，可能財務收到了這筆錢，結束了收款單流程後，他發現填錯了，本來應該收100，結果收款單寫的110。

但是，收款單表示的是過程，當這個過程結束了，我們就不會再需要上一個收款單了，所以，按照我們業務的處理流程，我們應該先生成一筆衝抵的收款單，例如收到-110，然後再生成新的100的收款單。

我們每個月還會有財務統計報表，財務報表因為和現實中的財務賬有關，是絕對不允許變動的，因此，這個財務報表就是一個結果表，我們會按月透過批處理程式，將收款單的明細和統計資料放到另一張表中，感覺好像比較冗餘，但是這個確實非常必要的。

因為我曾經就遇到過一個情況，我們直接用過程表來進行資料的統計，然後11月30日有一筆收款已經完成了，結果發現收錯了，就重新做了個收款單，結果本來已經出了11月結果的賬單發生了變化，導致財務實際的處理出現了問題。

因此，資料的冗餘有時候是有必要的，我們需要根據不同表的型別進行一些冗餘的設計。

資料庫設計是整個專案的骨架。骨架搭好了，專案順風順水，搭的不好，缺胳膊少腿。資料庫設計如此重要，小白完全沒必要擔心，因為輪不上你去設計！都是交給有經驗的人去做，你能看懂設計，完成功能開發就好了。

對於一些成熟的web框架，比如Django，資料庫結構搭建好了，剩下的都是自動化的。相反，如果資料庫結構比較草率，之後修改那是相當麻煩。有幾個原則：

1.少冗餘，基本單元儘量小，儘量用連線

2.預留擴充套件

3.欄位型別正確選擇

4.檢視觸發器可以設計，預留

其他的還有很多，這是個很專業的工作，複雜的還有什麼正規化簡化之類的，太複雜的還是推薦給專業人士處理。

tips：多看看中小規模的開源應用怎麼設計，可以借鑑。