資料庫是使用AWS的dynamodb
情境如下(我盡量把需求實體化說明，也順便整理自己的思路):
舉例來說，最複雜的情況，層級高且後設定，會覆蓋掉層級低、早設定的:
有考慮過當老闆更改設定時，將老闆的設定更新到所有中階管理職和底層員工
當中階管理職更改設定時，將中階管理職的設定更新到其管理的底層員工
但這樣個人會覺得目前總數少還沒問題，要是底層員工有數千數萬個，每次更新覆寫的次數就會很多，然而又不一定每個底層員工都會經常讀取設定值
(雖然這邊需求寫成老闆和員工，但實際上是產品而不是組織，所以確實有可能達到數千數萬個的等級，而不是想太遠了XD)
也考慮過給如上敘「語言」加上timestamp，在底層員工讀取設定時用來判斷該用自己的設定值或較高層級的設定值
但程式上的邏輯可能會變得難以閱讀、理解，且資料庫上上下下都有相同的欄位，但數值卻不同，其他人員維護起來可能也會感到困惑
希望能得到建議，取得查詢效能、費用及未來維護上的平衡，感謝
已邀請的邦友 {{ invite_list.length }}/5
你寫了那麼多
歸納起來只有一句話，就是
「如果必須二選一，這兩項動作的優先順序」
這兩項動作就是
1.更改設定
2.查詢設定
你要自己判斷的是
1.那項動作的「頻率」較高？(注意，就是頻率，跟「資料筆數」無關)
2.如果執行一次動作的時間一樣「長」(eg.10 秒鐘)，那項動作使用者比較無法接受？
如果讓我選的話
我會選擇減少「頻率高的那項動作」的執行時間
And 我猜是「查詢設定」
如果我猜對的話
就會把複雜(有多複雜就多複雜)的程式邏輯寫在「更改設定」動作裡
讓「查詢設定」的程式越單純越好
另外我好奇問一下
你後來有沒有去讀在職碩？
感謝，確實查詢的頻率會比更改高的多
但ddb不能像sql那樣一次查詢就能把符合條件的資料全改了(還是說……其實可以?)
所以才會想要盡可能減少費用的同時又好維護這樣
後來工作偏忙、家裡又出事情，心意也不決，所以還是沒去報在職碩
謝謝您的關心QQ
盡可能減少費用
我不太懂，為什麼你一直在費用上面打轉
ddb 的計價方式中分兩種
1.有基本費的
寫入容量單位 (WCU) 每個 WCU 0.00065 USD
讀取容量單位 (RCU) 每個 RCU 0.00013 USD
2.沒基本費的
寫入請求單位 每百萬個寫入請求單位 1.25 USD
讀取請求單位 每百萬個讀取請求單位 0.25 USD
與其在這個地方精打細算
就為了省那幾百塊美金/月
公司寧願節省員工每次查詢資料時花費的時間
把省下來的時間拿去賺錢還比較實在
大多數公司都是這樣的.
有時候，寫程式要先厘清好你的邏輯。
不覺得你4點的要求，已經有衝突性了嘛?
就如 a=b b=c a<>c 的意思一樣了。不要說你辦不到，我也辦不到這件事。
就已經不需要去討論程式規劃的問題了。
感覺好像在寫BOM表喔
如果是我，我會做一個異動檔，有四個欄位，分別是階層，屬性，屬性值，修改時間
初始化將所有的值寫入，底層員工A沒有說是哪個階層，我就不提了
階層 屬性 屬性值 修改時間
a 老闆 1 語言 英文 2021/03/10
b E 1.1 語言 英文 2021/03/10
c F 1.2 語言 英文 2021/03/10
d B 1.1.1 語言 英文 2021/03/10
e C 1.1.2 語言 英文 2021/03/10
f D 1.2.1 語言 英文 2021/03/10
g 老闆 1 語言 日文 2021/03/11
h E 1.1 語言 英文 2021/03/12
程式邏輯
假設要找B的屬性，先將最後修改B的時間d(2021/03/10)和屬性(英文)抓出
然後逐階層比對
因為B的階層為1.1.1
所以先找階層為1，最近修改時間g(2021/03/11)，時間比d後，所以異動時間改成2021/03/11，屬性改為(日文)
再找階層為1.1,最近修改時間h(2021/03/11)，因為時間比g後，所以異動時間改成20201/03/12,屬性改為(英文)
因為已到上一階，所以屬性為(英文)
因為D的階層為1.2.1，最後修改D的時間f(2021/03/10)和屬性(英文)
所以先找階層為1，最近修改時間g(2021/03/11)，時間比f後，所以異動時間改成2021/03/11，屬性改為(日文)
再找階層為1.2,最近修改時間c(2021/03/10)，時間在g前，所以異動時間不變,屬性不變
因為已到上一階，所以屬性為(日文)
iThome鐵人賽
看影片追技術