資料正規劃為避免資料的異常更新、刪除，將數據分庫分表，以key連結起來
第一正規式須遵守以下兩個規範
原始資料為
| 姓名 | 電話 | 商品 | 價格 |
|---|---|---|---|
| John | +9123 | 奶茶、紅茶 | 60、30 |
| Sam | +9124 | 綠茶、紅茶 | 30、30 |
| Jim | +9125 | 抹茶拿鐵 | 40 |
| Jim | +9125 | 抹茶拿鐵 | 40 |
| Timmy | +9126 | 青茶 | 35 |
以下表格經過1NF調整，並且給予訂單編號用以區別每個欄位的值
| 訂單編號 | 姓名 | 電話 | 商品 | 價格 |
|---|---|---|---|---|
| d01 | John | +9123 | 奶茶 | 60 |
| d02 | John | +9123 | 紅茶 | 30 |
| d03 | Sam | +9124 | 綠茶 | 30 |
| d04 | Sam | +9124 | 紅茶 | 30 |
| d05 | Jim | +9125 | 抹茶拿鐵 | 40 |
| d06 | Jim | +9125 | 抹茶拿鐵 | 40 |
| d07 | Timmy | +9126 | 青茶 | 35 |
以上商品以及價格欄位都是跟產品有關，以下表格經過2NF調整
| 訂單編號 | 姓名 | 電話 | 產品編號 |
|---|---|---|---|
| d01 | John | +9123 | c01 |
| d02 | John | +9123 | c02 |
| d03 | Sam | +9124 | c03 |
| d04 | Sam | +9124 | c02 |
| d05 | Jim | +9125 | c04 |
| d06 | Jim | +9125 | c04 |
| d07 | Timmy | +9126 | c05 |
| 產品編號 | 商品 | 價格 |
|---|---|---|
| c01 | 奶茶 | 60 |
| c02 | 紅茶 | 30 |
| c03 | 綠茶 | 30 |
| c04 | 抹茶拿鐵 | 40 |
| c05 | 青茶 | 35 |
消除資料表中的遞移相依，意思是在主表格中每個欄位應該都unique不互相依賴，向上表中姓名跟電話都是顧客資訊，因此應該再切分出來
| 訂單編號 | 客戶資訊 | 產品編號 |
|---|---|---|
| d01 | s001 | c01 |
| d02 | s001 | c02 |
| d03 | s002 | c03 |
| d04 | s002 | c02 |
| d05 | s003 | c04 |
| d06 | s003 | c04 |
| d07 | s004 | c05 |
| 客戶資訊 | 姓名 | 電話 |
|---|---|---|
| s001 | John | +9123 |
| s002 | Sam | +9124 |
| s003 | Jim | +9125 |
| s004 | Timmy | +9126 |
| 產品編號 | 商品 | 價格 |
|---|---|---|
| c01 | 奶茶 | 60 |
| c02 | 紅茶 | 30 |
| c03 | 綠茶 | 30 |
| c04 | 抹茶拿鐵 | 40 |
| c05 | 青茶 | 35 |
首先再進入database的查詢方式前要先了解database的資料結構，再現在大多數的資料庫多為B+ tree結構，再某些情況下，使用index=1取代name='Alice'下查詢性能較好
| index | name |
|---|---|
| 1 | Alice |
先從B tree架構開始介紹，以root為節點往下生長，root值為8往左邊走值(3、6)一定小於8，往右邊走值(10、15)一定大於8，但其有一明顯缺點，再進行index搜尋時，搜尋的速度不穩定，且當搜尋路線不佳時，會將整個tree遍歷造成搜索效能差。
假設今天要查找5~9的欄位，其查找為必須執行多次I/O
B+ tree改善B tree缺點，只將值儲存在最下層節點，中間層都以指標方式儲存，查找到最下層時，如果大於目前值往右邊查找，小於則往左邊查找，可以大幅減少並穩定查找次數。
今天要查找5~9欄位，查找只需進行3次I/O後再最下層節點依序往右就行
詳細可看以下參考文章，筆者在設計資料庫目前多為使用ORM去設計，ORM本身就有設計效能優化，但比起使用原始sql指令能有一些效能消耗轉換，因此以後如須追求高效能系痛會再將此塊摸清楚。
iThome鐵人賽
看影片追技術