資料庫設計的心法與一些可以思考的問題

 

起初先問自己幾個問題

What's it for ?

假設你正在搭建一個線上書店網站系統

可能我們可以很快速直接說出「資料庫需要儲存像是產品跟訂單等重要的資料」

，因為算是很成熟也十分常見的應用，不過聽起來稍微有些籠統模糊。

這個回答確實可能是對的，但我們更應該深入一層去探討該線上商城網站應用程式的目的是捨麼?

畢竟如果只是單純用於存放資料好像聽起來沒捨麼價值，再來就是可能不夠具體、你也無法開始去著手為了解決問題的資料庫設計。

畢竟愈具體描述跟紀錄需求，我們設計出來的DB系統才真正可發揮其價值。

可能當我們經過深層思考跟長期需求洽談後歸納出目的如下

「這套系統有能幫助客戶查找書籍，並且還能觀看到其他人對該書籍商品的評論，還要能夠追蹤各自訂單與購買紀錄，讓客戶可以去貢獻他們的評論，並根據有相似閱讀習慣的人瞭解潛在可能喜歡的商品。」

有沒有發覺，跟一開始的需求描述聽起來你會規畫出複雜度完全不同的資料庫。

What do you have?

1.是否存有既定的資料庫? 可能是Access 或是用Excel之類的在維護，甚至都用紙本?

這樣子會有捨問題?

聽起來你現行雖然有東西可以匯入資料，但仍不滿足你的實際需求。

比較實際案例就是一些中小企業、公司可能不想花錢或起初覺得一些電子單據不需要用ERP或特別客製化找人訂做系統，都用Excel維護，造就可能檔案無法共編，都是一人作業的問題。

也可能引發就是維護的資料相互想看的資料因無系統卡控跟規範導致格式不一致錯亂問題。

無法共編不是問題，也有公司透過google 雲端共享excel來達成多人共同編輯，但缺點想而意見撇除空間使用有限，一些權限劃分無法明確或是資料有機會被竄改的問題也是很多。

因此又回歸最初描述的「資料庫需要儲存像是產品跟訂單等重要的資料」

若遇到這類user回饋這樣子如此籠統的描述，請白眼並提出質疑那有excel跟google文件等方案，為何還需要資料庫?有何效益?

也有可能是資料有捨麼格式錯誤或沒統一，需要先做資料格式前置作業、跨team討論等等。

先抓住機會修復任何問題，再往資料庫創建設計走，避免重蹈覆轍。

2.是否有此資料庫將取代或能幫助到既定流程(or手動流程)的部分?

常見可能就是讓人詬病的紙本資料處理、檔案櫃找資料的不易，無法異地辦公、無紙化好拿ESG認證...etc，有些附加效益，有些有形或無形效益。

What tables do you need?

也就是你資料庫中的實體(名詞)，代表現實生活中某人事物。

比方客戶、產品、資產...etc。

What columns do you need?

根據每張table去規劃所需欄位有哪些、包含資料型態、長度。

What Keys do you need?

唯一識別的主鍵有時可能是單一欄位，也可能多個欄位來組成唯一識別性。

What Relations do you need?

例如:如果正在創建訂單，則該訂單與某一客戶相關聯，反過來說明就表示該名客戶購買一種或多種產品。

通常我們永遠不想浪費資料庫空間，也就是複製資料，存到重複的值，因此不希望把客戶資訊複製到訂單中或將產品資訊複製到訂單中。

相反，我們描述的是訂單table、客戶table和產品table之間的關係，就可很快看到如何定義這些關係，可以是一對一、一對多、多對多的三種對應關係。

比方: 客戶有多少訂單、有多少產品在特定訂單中，或反推回來透過訂單表找到特定產品並找到曾經訂購過的所有客戶。