單項記賬模式

我已經在以前的應用程序上建構了複式記賬模式，而且非常複雜。對於一個新應用程序，我想要盡可能簡單和最優雅的會計模式（交易量低且不復雜）。

• 人們可以通過他們網站上的廣告賺錢（例如 google adsense）
• 我們以不同的時間間隔（每週、每月等）向他們發放收入付款
• 他們的帳戶可以被借記（例如，他們的網站有欺詐機器人訪問），也可以記入貸方（註冊獎金，或者我們沒有支付足夠的技術錯誤）

在最簡單的形式中，我有一個transactions包含這些核心列的表（忽略其他絨毛列）：

• id（細繩）
• type（列舉：DEBIT/ CREDIT）
• description（細繩）
• amount（整數）

所有這一切都很好，只有兩個令人困惑的部分我希望有人告訴我我的解決方案是否合理。

1. 首先是收益需要以某種方式“結算”。欺詐和其他問題很常見，因此“實時”收入會不斷調整。如果沒有中間結算步驟，這些價格變化就會消失在乙太中。

transactions所以我的第一個想法是每天為前幾天的“結算”收入創造一個記錄。它可能看起來像這樣，包括一個展示“欺詐”範例：

"CREDIT", "User Earnings - Jan 3, 2021", 12021
"CREDIT", "User Earnings - Jan 4, 2021", 8319
"CREDIT", "User Earnings - Jan 5, 2021", 9130
"DEBIT", "Fraud Adjustment", 771

問題 1 是，“到目前為止，這看起來合理嗎？”

2. 下一個困惑涉及如何將付款 ( transaction) 與其他交易 (上面的 4 行) 清晰地聯繫起來。

如果我想支付上述 3 個收入行 + 1 個調整行，它看起來像這樣：

"DEBIT", "User Payment", 28699

這很好，只是它不在與該事務關聯的事務的數據庫中。一種解決方案可能是在事務上與自身建立多對一關係，但與其他事務相關聯的事務感覺“錯誤”。

我設想當管理員發出付款時，它會顯示所有未關聯交易的列表，旁邊有可供您選擇的複選框，這將使這些交易以某種方式與付款相關聯，然後它們就不會意外地被支付再次，因為它們將從列表中消失。

我最大的恐懼是重新發明輪子。如果它在現實世界中“正常”，我可以做一個更簡單的解決方案。我不想成為一個單一的開發人員，試圖“發明”一個實際上非常愚蠢並且很容易以不同方式解決的解決方案。

謝謝！

對於您的第一個問題，這是平衡Transactions. 每筆貨幣變化都應記錄為Transaction. 因此，無論您以何種速度合併諸如欺詐之類的事情，例如，每天一次（或每分鐘頻繁一次，只要您Transaction每次都記錄合併金額，這並不重要）將導致有多少此類Transactions到被生成。

對於您的第二個問題，它是一對多的關係並沒有本質上的錯誤，除了業務背景之外，這就是我最初想像的方式。重新引入業務環境，通常該領域的金融系統會通過日誌處理這些事情。期刊的概念通常用兩個表來表示，JournalHeader和JournalLines。代表通用資訊，JournalHeader例如創建者和創建時間，而JournalLines代表Transactions通過結算合併的個人。通常表上有一個欄位與合併JournalLines的原始源相關聯（通常是另一個表，例如，如果有生成transactions``SalesOrders``Transactions,將與他們合併JournalLines的原始數據相關聯）。SalesOrder這種關係本質上是一對多的，也是標準的。

我對此類的確切實施有點模糊（因為我有一段時間沒有使用過這種金融），但希望這有助於描繪畫面。長話短說，在結算 Transaction與其結算 之間建立一對多的關係是可以且正常的做法Transactions。

引用自：https://dba.stackexchange.com/questions/284985