1. 資料庫規劃說明

2. 雲端服務
1. 使用者帳號管理
2. 商品品項及分類管理
3. 金流交易處理
4. 帳務紀錄
5. 帳務報表分析
Architecture Define
Cloud Service
Mobile App
API

3. 品牌帳號
品牌帳號
品牌帳號
帳號管理
1. 各品牌業者擁有各自的總管帳號。
2. 平台註冊及付款以該帳號為主。
3. 各品牌對應⼀一個網路商店。
4. 若品牌有⼀一個以上的分店，
則總管帳號為總部帳號。
服務資料庫
用來記錄平台操作必要的資訊，包含
各商店帳號管理，商店及商品資訊及
各服務的授權期限等。
1. 記錄帳號資訊
2. 記錄帳號的授權時限
3. 各品牌衍生資料另存於
專屬資料庫中
Architecture Define
Cloud Service

4. 品牌帳號
品牌帳號
品牌帳號
分店
分店 分店
Architecture Define
Cloud Service
分店管理
1. 各品牌預設有⼀一分店。
2. 預設分店同時為網路商店。
3. 分店具有⼀一 ServiceId，
記錄於服務資料庫中。

5. 品牌帳號
品牌帳號
品牌帳號
分店
分店分店
分店 分店
分店 分店
Architecture Define
Cloud Service
分店管理
1. 各品牌可設立多個分店。
2. 各分店有獨立的ServiceId識別。
3. 各分店分別儲存地址及電話。
4. 各分店商品個別管理。
5. 為了方便日後建立商城用，
分店商品存於服務資料庫中。
各品牌帳號資料庫
用於記錄該品牌管理下衍生的資料。
以隨著操作累積的資料為主。
1. 包含員工資料，操作記錄。
2. 記錄各店交易資料及統計資料，
以作為報表分析之用。
3. 紀錄未來衍生服務所需資料。

6. Cloud Service
品牌帳號 分店
分店
分店
為何各品牌分店資訊存於服務資料庫中？
1. 商店資訊查詢為網站服務之⼀一，因此統⼀一管理。
2. 方便未來擴充前端消費者服務，例如查詢附近店家。
3. 方便線上購物車系統集中管理商品。
4. 方便未來提供商店搜尋功能，或跨商店的商品搜尋。
Architecture Define

7. Platform Service

8. 品牌帳號資料庫
（每⼀一個品牌⼀一個資料庫）
服務資料庫
（只有⼀一個）
Database Schema 目前資料庫結構
服務資料庫儲存的資料為服務的核心資料，
核心資料為運作系統必要的資料，需要妥善保護。
品牌帳號資料庫，儲存的是個品牌日常營運衍生的資料，即
使意外使資料消失，也不影響系統的運作。

9. Available Solutions
多資料庫架構
主要資料庫儲存平台服務資
訊，並為每個帳號分別開立
資料庫以儲存其交易資料。
每個資料庫加上品牌ID作區
別。
單⼀一資料庫架構
為每個帳號開⼀一系列的資料
表。以目前的架構，每個帳
號需另外開十個資料表，每
個資料表命名加上品牌ID以
為區別。
NO SQL架構
使用市面上提供的NO SQL
架構，打破資料表架構。雲
端服務多採用此架構，但該
架構在搜尋機制上，仰賴事
前規劃，不易事後發展新服
務。
可供參考的資料庫架構規劃

10. Available Solutions 各資料庫架構比較
多資料庫架構 單資料庫架構 NO SQL架構
解決搜尋速度問題
人工管理複雜度
個別帳戶資料備份及移轉
即時資料統計分析
Schema變更
架構擴充彈性
海量資料需求
資料統計作業方式
easy easy hard
easy hard easy
easy hard easy
easy easy hard
hard hard easy
入口資料庫與各業者區域資料庫易切割 遇到需求的時候再重新改寫 切割容易，彈性大
直接移植到虛擬化平台（雲端） 資料表數量有邏輯上限，須改寫 直接移植到虛擬化平台（雲端）
SQL語法 SQL語法 預先規劃快取

11. Reasons
集中的帳號授權付費管理
各品牌帳號註冊，付費，及授權期
限的控管等，為系統主要業務，因
此統⼀一歸在服務資料庫中存取。
統⼀一且大量的帳號管理
若要經營品牌，則可能會有統⼀一的
註冊入口，因此，若提供跨國服務
時，可能帳號部分的控管還是要集
中，並且記錄帳號所屬分區，在分
交給區域的伺服器處理。
跨所有品牌的商店及
商品資訊搜尋
若未來預計提供消費者利用手機查
詢附近可消費的商店，或者可購買
的商品，則需要在商店資訊當中做
搜尋，因此商店資訊必須集中存放
在服務資料庫上。
累積交易資料做報表統計
⼀一般商店資料需保存五年，⼀一個分
店內⼀一個月內銷售的商品項次約為
4000 筆，存放ㄧ年約為48000。隨
著時間累積，資料的量就會越大。
如果各廠商共用資料庫的話，後期
加入的商店即使資料不多，其搜尋
速度也會受到影響。
假設有⼀一百家店累積⼀一年的交易資
料，這使得每次分析都要在
4,800,000資料中做統整，會使得各
別商店的搜尋效率降低。透過資料
庫的切割，各商店的報表只在自己
的資料庫內搜尋，可以避免無謂的
運算資源浪費。
品牌資料移轉、備份等需求
客戶在營運過程中，難免會有資料
移轉的情況，即使不允許移轉到其
它平台，但同⼀一平台間的資料移轉
也是可能的。對於整個品牌的資料
搬移，如果資料表全放在同⼀一個資
料庫，會使得操作不易。但放在個
別資料庫中，則可以直接對資料庫
做備份或移轉操作。
考慮手動操作資料庫的情形
偶而會有⼀一些難以分辨的操作錯
誤，如連線不穩導致部分的資料出
錯，或預期外的人為操作疏失。
（例如發票打錯號碼，過了⼀一個月
才發現）
這類疏失發生的機率偏低，全部做
操作界面給使用者並不划算，因此
就需要手動操作。這時候若大量資
料表混再⼀一起，光是搜尋資料表可
能就連線Timeout導致無法管理。
未來利用累積的交易記錄
做分析
商品交易資料未來可以做許多利
用，例如特定地區的消費趨勢分
析，特定時間的商品熱賣狀況分析
等，這些都是未來能夠銷售的資
訊，透過資料庫搜集海量資料的目
的，就是為了累積這些資源。
理由說明

12. Reasons 結論
• 資料表放在⼀一起最主要的問題是IDE
由於各品牌底下的資料表也不少，考慮⼀一千家商店時，約會有⼀一萬個資料表，光是用
IDE管理時，可能就會經常遇到介面Timeout難以操作的問題。但是採用分資料庫的架
構，在透過SQL Management Studio連入時即可選定指定資料庫，不會因為顧客數量過
多而導致管理不易。
• 目前的架構也並非最理想
未來為了加速服務，常用的報表及分析統計，仍舊需要用計數器或快取得方式來改
善。此二做法需要很清楚使用者的需求，規劃跟開發上複雜度也較高，為了不影響上
線時程，目前採用資料庫的機制是較為簡單快速的做法。
• 未來主資料庫跟各店資料庫分離機會大
當使用者數量操作主機負荷時，勢必需要調整Loading Balance架構，此時便可將主資
料庫作為主要入口使用，因為即使有十萬家的商店，在主資料庫內所耗用的搜尋量仍
舊不大。而各店家的資料，則可根據店家實際所在地區來配置到不同地區的資料庫主
機使用。