已經快要想不出有趣的標題了,從昨天的文章中應該就知道,最後的幾天的內容相對會比較繁瑣枯燥,而且會以觀念為主。在今天和明天的文章中,我們要來思考的問題是,到底應該...
假設要設計雲端載具系統,基本上會有會員資料、發票資料去紀錄資料。但其中的發票資料,我認為至少要用三張表格去儲存,分別為手動輸入的發票、財政部查詢的正確發票及購買...
回顧一下前幾天的 MongoDB 資料庫設計,應該有留意到不論是在傳統發票、紙本電子發票以及載具,我都是利用 tag 來做區隔,這是為了可以將資料全部都塞在同一...
昨天我們用了網購服務的新創團隊,來解釋資料庫正規化後可能遇到的資料運用瓶頸。橫空出世的資料工程師透過另建一個資料庫整合來自各服務的資料,記載歷來變化並提供決策...
在這次 30 天挑戰的第一階段-資料庫設計篇,我們從資料本身出發,關注資料收集管道、儲存架構設計、資料擺放層次及取用的成本等。實踐這些資料庫設計的準則就是資料工...