在Web應用程序中存儲貸項餘額的最佳實踐

我正在創建一個Web應用程序，用戶可以在其中購買貸項（使用真實貨幣）並將其用於物品。在Web應用程序中存儲貸項餘額的最佳實踐

我將需要保持每次用戶購買或花費信用的歷史。

我經常需要知道用戶的當前貸方餘額。

我通常工作的原則是兩次存儲相同的數據是不好的做法，即因爲我有一個所有信貸餘額增加和減少的歷史，我不應該把餘額本身存儲爲一個單獨的字段。

但是，每次用戶打開一個新頁面（將顯示其當前餘額）時，計算此平衡似乎有點矯枉過正。另一方面，將它存儲在數據庫或網絡服務器的內存中似乎是錯誤的，只是爲了防止系統每次都必須處理它。

有沒有人有這方面的經驗和/或知道什麼建議的最佳做法是這種情況？

2013-03-21 GGG

我從事過幾個具有相似需求的項目，在即時計算當前餘額方面沒有任何問題 - 這是最容易出錯的解決方案，這種查詢是大多數數據庫設計的目的;除非你在一個Facebook流量級別的網站上工作，像"select sum(transactionValue) from transactions where userID = ?"這樣的網站應該是非常快的。

在其他地方存儲餘額 - 重複它 - 實際上 - 可能會引入細微的錯誤和差異，「緩存」值與基礎事務不同步;獲得這項權利所需的工作量可能很重要。

來源

2013-03-21 09:25:52

Denormalization確定它的位置。例如，一個包含論壇主題的表格也有一個PostCount列，而不是爲每個主題做一個COUNT(posts)。如果您擔心一致性，並且您應該，您可以安排每個用戶的Balance與他們的交易總和相匹配的定期檢查（例如，來自或發給給定用戶的每次交易）。

來源

2013-03-21 09:25:29 CodeCaster

是的問題是，當檢查發現Postcount！= COUNT（Posts）時該怎麼辦。 – GGG 2013-03-21 09:34:58

@GGG當然，實際的帖子表（或您的交易日誌）在出現差異的情況下是領先的。 – CodeCaster 2013-03-21 09:52:09

不計算每個請求的貸方餘額。
每個用戶的貸方餘額是你應該維護的。

保留在您的數據庫中。
這樣你就不必擔心併發。
當用戶使用您的應用程序時，使用事務來增加遞減此值。
數據庫確實對重複選擇進行了優化，所以再次讓你的db處理這個問題。

來源

2013-03-21 09:26:31 nunespascal

計算餘額是否需要時間？如果不是，只需使用SQL實時計算。

但是，當您的交易日誌變得越來越大（數百萬行）時，我正在預見未來的問題。當從事務日誌中選擇查詢需要時間時，那麼是時候緩存並預先計算餘額並將其存儲在數據庫中。

來源

2013-03-21 09:27:24

在Web應用程序中存儲貸項餘額的最佳實踐

回答

相關問題