Q16. [個人技能題組][Backend] 功能：後台管理者訂購商品統計 API。

[wildwindjen]

月統計表：選擇購買月份出現該月份各商品的統計數字（總金額、總數量），並且可以匯出成 excel。

a. 你怎麼計算總額、數量的？這樣的方式好處/壞處在哪？
b. 如果資料很多，匯出 excel 可能會有什麼問題？該怎麼解決？
c. 請提供驗收項目清單。

答題時間: 24 hr

[PenguinRun]

「於2017/04/26 開始答題」

controller
model

a. 你怎麼計算總額、數量的？這樣的方式好處/壞處在哪？
能透過sql, JS及excel來進行計算。

• 總額：sql語法

• 數量：sql語法

• 月收入總額：因想直接一行sql query解決所以這部份透過JS計算。

• 使用sql語法好處：

  • 使用sql語法能夠省略許多JS計算的程式碼且不需要在額外透過excel語法來進行計算。

• 使用sql語法壞處：

  • 增加DB的負擔（其實也還好）。
  • 一長串的sql query語法

b. 如果資料很多，匯出 excel 可能會有什麼問題？該怎麼解決？

• 問題
  • 會超過excel的workbook的承載
  • 在生成excel檔案時造成硬體負擔
  • 使用者在閱覽上不易
• 解決
  • 初步設計好excel的格式
  • 控制excel輸出資料的大小，若單月資料量太多，則製作多個excel報表來呈現。

c. 請提供驗收項目清單。

驗收「DB錯誤情況」

• 測試資料：「輸入錯誤DB密碼」，預期節果：「回應：伺服器錯誤，請稍後在試！」
• 測試資料：「輸入錯誤DB帳號」，預期結果：「回應：伺服器錯誤，請稍後在試！」
• 測試資料：「輸入錯誤DB資料庫」，預期結果：「回應：伺服器錯誤，請稍後在試！」

驗收「query必填欄位」

• 測試資料：「/?year=2017&month=4」，預期結果：「正確」
• 測試資料：「/?year=&month=4」，預期結果：「回應：請在query中輸入正確的year！如：year=2017」
• 測試資料：「/?year=t&month=4」，預期結果：「回應：請在query中輸入正確的year！如：year=2017」
• 測試資料：「?year=2017&month=」，預期結果：「回應：請在query中輸入正確的month！如：month=4」
• 測試資料：「?year=2017&month=t」，預期結果：「回應：請在query中輸入正確的month！如：month=4」

驗受「資料庫若無資料」

• 測試資料：「/?year=2017&month=4」，預期結果：「產出excel檔案。回應：The workbook was created!」
• 測試資料：「/?year=2017&month=3」，預期結果：「該月份沒有資料！」

輸出長這樣

Excel

檔名為：「2017-4月-月報表.xlsx」

注：蛋糕在加乘上有錯誤是因為當初測試產品update資料時，有動到產品的資料所以就後面的總額數字對不上，但整體運作是正常的。

「於2017/04/26 答題結束」

[dustfantasy]

「於2017/04/26 開始答題」

a.將訂單與產品的table進行join主要取出產品id、價格、出貨數量、付款日期，以sql指令sum進行總額與數量的計算。
好處:以sql進行加總後不用額外在程式碼編寫加總程式。
壞處:sql指令很長閱讀不易。

b.
因為excel每個Sheet都有一個大小限制，過大的資料量會造成超出範圍而出錯。
在資料量過大時應該分成數個Sheet，如此以來可以解決此項問題，另外適當的分Sheet在讓excel執行運算之類的操作可以更加快速。

c.
A.報表結果是否正確
1.當月該商品無訂單仍會印出總額數量為零
查詢無訂單的月份，預期輸出數量總額欄位值為零。
2.確認最後一天的訂單時間有計算到
建立一筆在月份最後一天的訂單執行API查看結果。

B.下載報表前是否有驗證為管理者
1.使用root帳號的token，預期結果能下載檔案。
2.使用普通帳號的token，預期結果收到無權限訊息。
3.不使用token，預期結果收到無權限訊息。

「於 2017/04/26答題結束」

[wildwindjen]

@dustfantasy 要挑戰想想「加總」的動作什麼時侯適合在程式做，而不是 db 嗎？

[YenChunchen]

「於2017/04/27 開始答題」
a. 你怎麼計算總額、數量的？這樣的方式好處/壞處在哪？
用程式計算,因為table設計成一個欄位擺放多個品項,故無法用SQL運算;如果計算量較大,程式運算效能較差
b. 如果資料很多，匯出 excel 可能會有什麼問題？該怎麼解決？可能會超過excel檔最大資料的負載,事先了解資料量大小,選擇適用的儲存格式(xlsx or csv...),如單月資料過大可選擇分成多個sheet或檔案存放
c. 請提供驗收項目清單。
1.驗證month,year欄位是否正確

• month,year任一欄位為空值或不存在,預期回應(該月報表不存在)
  *以上得到預期結果則通過month,year欄位驗證

2.驗證該月是否有報表資料

• 輸入month=4,year=2300,預期回應(該月報表不存在)
• 輸入month=4,year=2017,預期回應(顯示當月的月報表)
  *以上得到預期結果則通過該月報表資料驗證

3.驗證是否產生月報表excel檔及資料是否正確

• 輸入month=4,year=2300,預期回應(該月報表不存在)
• 輸入month=4,year=2017,預期回應(顯示當月的月報表, 專案目錄下新增excel檔,且欄位正確)
  *以上得到預期結果則通過excel檔及資料驗證

[dustfantasy]

@wildwindjen
以此題為例，我認為會是取出的那些基本的資料還有額外用處時應該在程式處理，如此一來資料庫不用為了處理重複資料而一再讀取。
訂單中的欄位有account,productid,quentity,paytime，若要把符合的資料全數印出那會抓取到大量沒必要的資料，使用sum可以直接在ｄｂ中進行運算而最後產出的表可以縮減成一樣商品一行的小表，而不用產出有大量重複資料的表。
然而若對於訂單中的資料還有額外的用處，像是要計算各式各樣的統計，那在sql中就必須增加好幾個運算欄位，同時也有可能會因此要連結數個表而造成一定的混亂，因此個人覺得在sql的可讀性與不想為資料庫增加負擔的考量下，就適合在程式做運算。

[wildwindjen]

我的經驗上還有一種可能：「當 DB 資源很珍貴的時候」。
舉例來說：以前有碰過單一 DB 資源要同時應付多個 Web 應用程式。如果運算集中在 DB ，一旦 DB 過忙，就會連帶影響所有的應用程式，這時候就偏好在應用程式上做。

[HoHow]

「於2017/05/24 開始答題」
月統計表：選擇購買月份出現該月份各商品的統計數字（總金額、總數量），並且可以匯出成 excel。

a. 你怎麼計算總額、數量的？這樣的方式好處/壞處在哪？
有一個cart_item的資料表來儲存會員購買的數量與總額，而不是直接從product的表去做運算，這樣的話會員的資料不會有錯誤，一定是當下購買的價格，如果是從product抓的話，會是最新的價格，這樣訂單的價格就會有問題
b. 如果資料很多，匯出 excel 可能會有什麼問題？該怎麼解決？
使用者會等待太久以為是當機，透過適當的sheet來解決這個問題
c. 請提供驗收項目清單。

輸入query ?year=2017&month=5

month和year輸入正確值 預期結果：取得當月報表

year空值 預期結果：year不能為空
month空值 預期結果：month不能為空

year非數字 預期結果：請輸入正確year數值
month非數字 預期結果：請輸入正確month數值

產生報表excel

輸入正確的month和year 預期結果：成功下載excel
錯誤的值和上面結果一樣

「於2017/05/24 答題結束」