紀錄 Materialized Views 與 實體表的副本 做法真的一樣？ What’s the catch? 差異在 前者 會額外占用 memory， 因此最好用在更有價值的查詢結果快取上， 別想著拿來替代 AB表切換。 ref: Understanding Materialized Views — Part 1 Materialized Views: The Cost-Effective Way To Extract Insights Why Use a Materialized View?

一個 Batch Task 遇到一段 Code， SQL.Select in a for-loop that runs 25k times 特別是 for-loop 內 以 await 去使用了 async 的 DB Layer Func. 我請團隊在 Parallel 的修改版本加上限制。 var parallel = new ParallelOptions { MaxDegreeOfParallelism = 5 }; 也與另一個做法 Task.Run, Task.WhenAll 進一步區隔。 ref: Running Async Foreach Loop C# async await Parallel.ForEach vs Task.Run and Task.WhenAll https://gitter.im/npgsql/npgsql?at=595a0319c101bc4e3a46654d 系統式思考 這個課題在團隊內的討論很有趣， 討論過程中對於可能的問題不乏 AP Logic 有問題、SQL 有問題、…， 但卻不太動手實測每段時間。 那段邏輯在開發環境中執行一個 SQL SELECT Query 約 2ms， 但 For Loop 高達 3萬筆資料， 在 不修改 AP 主 Logic & SQL 的前提下可發揮的空間有限（數位轉型日常，除非先完成驗證過結果正確）， 因此團隊將 部分邏輯 改為 Parallel 是可以進行嘗試的。 （前提是該 AP Logic 不會因此修改造成 髒資料）...

將 Docker 映像部署至 Azure 容器執行個體

易經《彖辭》中有十二卦提到「時」的「大矣哉」。 孔子晚年讀《易經》最有感想的是 『時也，命也。』 孫子曰： 『昔之善戰者，先為不可勝，==以待敵之可勝==。不可勝在己，可勝在敵。故善戰者，能為不可勝，不能使敵之必可勝。故曰：勝可知，而不可為。』 『故善戰者，求之於勢，不責於人，故能==擇人而任勢==。任勢者，其戰人也，如轉木石。木石之性，安則靜，危則動，方則止，圓則行。故善戰人之勢，如轉圓石於千仞之山者，勢也。』 宣揚實踐理念、做事、…. 都講求這個… 難得糊塗~~

紀錄一下 考量點 schema_version。 幾乎可以優先從「商業邏輯」、「畫面呈現」 等 high level來開始規劃。 document 是原子操作（atomic operation），規劃時必須考量「寫入、更新」頻繁程度，適度將 document 分散。 預先安插可用於 sharding 的設定欄位。 The Bucket Pattern 很適合 IoT、巡查表單類 的資料放置。 The Subset Pattern 文中提到的 Product - Reviews 案例很實用。 Product Collention 內紀錄前 10個 Review， 可以做為產品資訊頁「第一擊」的資訊儲存， 進一步的資訊再從其他 Collection 撈取。（如：Review） Reference： Data Modeling for MongoDB Building with Patterns: A Summary