身為 Backend Camp 學員，不能不懂資料庫的基本使用！但初學資料庫之後，要如何在專案實作上跟別人討論、甚至是分工協作呢？

接觸專案以後我才開始聽到 ER Diagram 這個名詞，也有聽過有人直接稱 schema、ER 圖 等名詞。這些圖表對於工程師來說有點麻煩，但如果好好運用，會是溝通與思考上很大的利器！

ER Diagram（實體關係圖）是什麼？

(此處引述 ChatGPT)

ER Diagram（實體關係圖）是一種用來視覺化和描述數據模型的工具，它以圖形方式表示數據實體之間的關係。

定義：

1. 實體（Entity）：ER Diagram中的實體代表現實世界中的一個物件、概念或事件，通常用名詞表示，如「顧客」、「產品」、「訂單」等。
2. 關係（Relationship）：關係表示不同實體之間的相互作用或連接，描述它們之間的相依性。關係可以是一對一、一對多或多對多的。

用途：

1. 數據建模：ER Diagram是數據建模的重要工具之一。它幫助數據專家、數據庫設計師和開發人員理解和捕捉系統中的數據結構，包括實體、屬性和關係。
2. 數據庫設計：在設計關聯式數據庫時，ER Diagram用於定義表格（或實體）之間的關係。這有助於確定數據庫的結構，並確保數據能夠有效地存儲和檢索。
3. 系統分析和設計：在軟體開發過程中，ER Diagram用於系統分析和設計階段，以確定應用程序的數據需求並建立數據模型。
4. 通信工具：ER Diagram可以用作溝通工具，幫助不同利益相關者之間更好地理解數據結構和系統設計。它們能夠以圖形形式清晰地展示數據模型，減少誤解和沟通問題。

ER Diagram是一種強大的工具，用於可視化和設計數據模型，以便更好地理解數據之間的關係，促進數據庫設計和軟體開發過程中的有效溝通和設計決策。

推薦參考：

詳細的定義 Lucidchart 的這篇文章非常清楚，建議大家有空可以看看（或是要查詢時使用）。

而我在專案中的用途，多為釐清自己對專案架構的內容、也是圖像化與人討論的工具。

以部落格專案為例

舉例來說，一般專案常見文章部落格：

「每篇文章都有一位作者、一位作者可以有很多文章（一對多），
文章底下作者和其他使用者可以進行很多留言（一對多）」

上面引號的文字描述，可以換成下面的圖示

部落格專案也許還不用畫出 ER Diagram，但想像如果是大一點的專案，資料庫會有很多張表，那畫成圖像勢必會更加容易理解與溝通方便，這也是共同合作專案重要環節。

本次作為舉例的購物車專案

更詳細一點，可以把所有 table 的欄位列出來，幫助你更好思考每個實體之間的關係、相同與相異欄位：

如同昨日所述，我的實體會有團購、團購內產品項目、會員、購物車、訂單等：

• 上面這張 ER Diagram 中，我的 團購 groups 會有一張 首頁圖片 group_images、以及團購內的產品品項 products。（Laravel 預設 table 名稱皆為複數）
• 會員 users，團購發起人 organizer_id 及加入購物車的使用者 user_id 都源自於這張表。
• 當 user 加入 products 到購物車，每個 user 可以加入很多 products、每個 product 也可以被很多users 加入，如此會形成多對多 (Many to Many) 關係，需要有一張中介表 pivot table。(Laravel 預設名稱為 product_user，這裡自定義名稱為 shopping_carts )
• 當購物車確定被結帳，資料要複製到 訂單 oders 中，並有 訂單明細 order_details 載明哪幾筆資料、品項都屬於同一筆訂單

設計重點 1：訂單為「紀錄」概念，不要直接關聯

一開始設計時很常想說：

我有 products table ，那我的訂單明細中，產品品項是不是寫 product_id 就好，其他產品名稱等資料關聯到 products table 取用？

如果依照這樣設計，A顧客買了恐龍鑰匙圈，結帳後，產品名稱被更改為公主鑰匙圈，那當A顧客查看訂單時，因為只用product_id=1進行查詢關聯，原本的恐龍鑰匙圈就會變成公主鑰匙圈了，那究竟A顧客買的是哪個鑰匙圈呢？

這個「紀錄」概念很常用在訂單、維修單、紀錄單等資料庫實體上，結帳時要把購物車項目直接複製存進訂單及訂單明細，當下結帳是恐龍，就要一併把「恐龍」存進訂單，事後無論怎麼修改 products table 都不會影響訂單，有點像常見的「產品快照」功能。

建議可以在設計時多想想：「如果上游關聯異動、這張表的資料能不能被異動呢」 去思考噢！

設計重點 2：訂單要不要有「總金額」欄位？

我原先的設計中，orders table 有個「總金額」欄位，想說前端會顯示就直接存進資料庫。

經過後端夥伴 Will 提醒才發現，

那如果訂單明細有異動，某個產品項目價錢更動、或取消，這樣總金額欄位是不是得要一直維護？

懶畢竟是人的天性，在這個專案中，總金額可以直接撈出訂單明細加總，每次顯示時再進行加總，最不會錯也最不用怕維護時忘記。

當然最終還是要依照專案需求進行設計，建議規劃時可以多加考慮這一點！

怎樣的設計才是好設計？

初次嘗試自己規劃，老想著是不是太菜，直到前輩跟我說：

沒有一定要怎麼樣的設計，每個設計都是依照專案需求，符合專案需求就是最好的。

以上是我針對這個專案的 Database 考量與設計，能加強的地方當然還很多，但就先這樣吧！不試試看怎麼知道呢 ～～～