資料庫規劃說明

雲端服務

1. 使用者帳號管理2. 商品品項及分類管理3. 金流交易處理4. 帳務紀錄5. 帳務報表分析

Architecture Define

Cloud Service

Mobile App

API

品牌帳號

品牌帳號

品牌帳號

帳號管理

1. 各品牌業者擁有各自的總管帳號。2. 平台註冊及付款以該帳號為主。3. 各品牌對應⼀一個網路商店。4. 若品牌有⼀一個以上的分店，則總管帳號為總部帳號。

服務資料庫

用來記錄平台操作必要的資訊，包含各商店帳號管理，商店及商品資訊及各服務的授權期限等。1. 記錄帳號資訊2. 記錄帳號的授權時限3. 各品牌衍生資料另存於專屬資料庫中

Architecture Define

Cloud Service

品牌帳號

品牌帳號

品牌帳號

分店

分店 分店

Architecture Define

Cloud Service

分店管理

1. 各品牌預設有⼀一分店。2. 預設分店同時為網路商店。3. 分店具有⼀一 ServiceId，記錄於服務資料庫中。

品牌帳號

品牌帳號

品牌帳號

分店

分店分店

分店 分店

分店 分店

Architecture Define

Cloud Service

分店管理

1. 各品牌可設立多個分店。2. 各分店有獨立的ServiceId識別。3. 各分店分別儲存地址及電話。4. 各分店商品個別管理。5. 為了方便日後建立商城用，分店商品存於服務資料庫中。

各品牌帳號資料庫

用於記錄該品牌管理下衍生的資料。以隨著操作累積的資料為主。1. 包含員工資料，操作記錄。2. 記錄各店交易資料及統計資料，以作為報表分析之用。

3. 紀錄未來衍生服務所需資料。

Cloud Service

品牌帳號 分店

分店

分店

為何各品牌分店資訊存於服務資料庫中？

1. 商店資訊查詢為網站服務之⼀一，因此統⼀一管理。2. 方便未來擴充前端消費者服務，例如查詢附近店家。3. 方便線上購物車系統集中管理商品。4. 方便未來提供商店搜尋功能，或跨商店的商品搜尋。

Architecture Define

Platform Service

品牌帳號資料庫（每⼀一個品牌⼀一個資料庫）

服務資料庫（只有⼀一個）

Database Schema 目前資料庫結構

服務資料庫儲存的資料為服務的核心資料，核心資料為運作系統必要的資料，需要妥善保護。

品牌帳號資料庫，儲存的是個品牌日常營運衍生的資料，即使意外使資料消失，也不影響系統的運作。

Available Solutions

多資料庫架構

主要資料庫儲存平台服務資訊，並為每個帳號分別開立資料庫以儲存其交易資料。每個資料庫加上品牌ID作區別。

單⼀一資料庫架構

為每個帳號開⼀一系列的資料表。以目前的架構，每個帳號需另外開十個資料表，每個資料表命名加上品牌ID以為區別。

NO SQL架構

使用市面上提供的NO SQL

架構，打破資料表架構。雲端服務多採用此架構，但該架構在搜尋機制上，仰賴事前規劃，不易事後發展新服務。

可供參考的資料庫架構規劃

Available Solutions 各資料庫架構比較

多資料庫架構 單資料庫架構 NO SQL架構

解決搜尋速度問題

人工管理複雜度

個別帳戶資料備份及移轉

即時資料統計分析

Schema變更

架構擴充彈性

海量資料需求

資料統計作業方式

easy easy hard

easy hard easy

easy hard easy

easy easy hard

hard hard easy

入口資料庫與各業者區域資料庫易切割 遇到需求的時候再重新改寫 切割容易，彈性大

直接移植到虛擬化平台（雲端） 資料表數量有邏輯上限，須改寫 直接移植到虛擬化平台（雲端）

SQL語法 SQL語法 預先規劃快取

Reasons

集中的帳號授權付費管理各品牌帳號註冊，付費，及授權期限的控管等，為系統主要業務，因此統⼀一歸在服務資料庫中存取。

統⼀一且大量的帳號管理若要經營品牌，則可能會有統⼀一的註冊入口，因此，若提供跨國服務時，可能帳號部分的控管還是要集中，並且記錄帳號所屬分區，在分交給區域的伺服器處理。

跨所有品牌的商店及商品資訊搜尋若未來預計提供消費者利用手機查詢附近可消費的商店，或者可購買的商品，則需要在商店資訊當中做搜尋，因此商店資訊必須集中存放在服務資料庫上。

累積交易資料做報表統計⼀一般商店資料需保存五年，⼀一個分店內⼀一個月內銷售的商品項次約為 4000 筆，存放ㄧ年約為48000。隨著時間累積，資料的量就會越大。如果各廠商共用資料庫的話，後期加入的商店即使資料不多，其搜尋速度也會受到影響。

假設有⼀一百家店累積⼀一年的交易資料，這使得每次分析都要在4,800,000資料中做統整，會使得各別商店的搜尋效率降低。透過資料庫的切割，各商店的報表只在自己的資料庫內搜尋，可以避免無謂的運算資源浪費。

品牌資料移轉、備份等需求客戶在營運過程中，難免會有資料移轉的情況，即使不允許移轉到其它平台，但同⼀一平台間的資料移轉也是可能的。對於整個品牌的資料搬移，如果資料表全放在同⼀一個資料庫，會使得操作不易。但放在個別資料庫中，則可以直接對資料庫做備份或移轉操作。

考慮手動操作資料庫的情形偶而會有⼀一些難以分辨的操作錯誤，如連線不穩導致部分的資料出錯，或預期外的人為操作疏失。（例如發票打錯號碼，過了⼀一個月才發現）

這類疏失發生的機率偏低，全部做操作界面給使用者並不划算，因此就需要手動操作。這時候若大量資料表混再⼀一起，光是搜尋資料表可能就連線Timeout導致無法管理。

未來利用累積的交易記錄做分析商品交易資料未來可以做許多利用，例如特定地區的消費趨勢分析，特定時間的商品熱賣狀況分析等，這些都是未來能夠銷售的資訊，透過資料庫搜集海量資料的目的，就是為了累積這些資源。

理由說明

Reasons 結論

• 資料表放在⼀一起最主要的問題是IDE由於各品牌底下的資料表也不少，考慮⼀一千家商店時，約會有⼀一萬個資料表，光是用IDE管理時，可能就會經常遇到介面Timeout難以操作的問題。但是採用分資料庫的架構，在透過SQL Management Studio連入時即可選定指定資料庫，不會因為顧客數量過多而導致管理不易。

• 目前的架構也並非最理想未來為了加速服務，常用的報表及分析統計，仍舊需要用計數器或快取得方式來改善。此二做法需要很清楚使用者的需求，規劃跟開發上複雜度也較高，為了不影響上線時程，目前採用資料庫的機制是較為簡單快速的做法。

• 未來主資料庫跟各店資料庫分離機會大當使用者數量操作主機負荷時，勢必需要調整Loading Balance架構，此時便可將主資料庫作為主要入口使用，因為即使有十萬家的商店，在主資料庫內所耗用的搜尋量仍舊不大。而各店家的資料，則可根據店家實際所在地區來配置到不同地區的資料庫主機使用。