ユーザーごとの支払いビジネスモデルの実装
前書き
私は、組織が「環境」に追加するユーザーごとに料金を支払うアプリケーションに取り組んでいます。組織にはクレジット/残高があり、ユーザーが削除されない限り、組織はユーザーごとに少額の時間料金を支払います。組織は、定期支払いと一括支払いのどちらかを選択できます。支払いごとに請求書が作成されます。
私はこれを実装するための最良の方法を見つけようとしています。これまでのところ、私は2つの可能な解決策を考え出しました。
オプションA
最初に考えられる解決策は、ユーザー、支払い、価格設定に関するシステムのすべての状態変化を「ログに記録」することです。
組織がユーザーを追加または削除すると、ログエントリが書き込まれます。支払いが行われると、ログエントリが書き込まれます。価格が変更されると、ログエントリが書き込まれます。関連するすべての状態が記録されます。
これらのログを使用して、アプリケーションはクレジット/残高を計算できます。
オプションB
2番目に考えられる解決策は、物理的なクレジット/残高を実装することです。すべてをログに記録する代わりに、組織のクレジット/残高からユーザーごとの料金を差し引く1時間ごとのcronジョブが実行されます。
この2番目のオプションは、私にははるかに簡単に思えます。複数のテーブルとレコードを使用して、あらゆる種類の複雑な計算を行うことを回避します。とにかく支払いなどを記録する必要があるかもしれませんが、クレジット/残高を決定するためにそれらのログを使用していません。
何かご意見は？この種のシステムを実装するための最良の方法は何ですか？
編集
@Ewanの答えを検討した後、彼は良い点を挙げていると思います。そのため、オプションA、またはオプションAのようなものを使用します。
これが私が作成した単純化されたDBスキーマです：
これはうまくいくように見えますか？
オプションAははるかに優れています。
Cronジョブがクラッシュし、週末に実行されないことを想像してみてください。または、バグを見つけて、それが何年にもわたって価格をわずかに間違って計算していた。あなたは正しい請求書を理解する方法がありません。
このようなシステムでは、結果をどのように確認するかを検討する必要があります。したがって、正しく請求できるだけでなく、戻って請求計算を説明し、それが正しいことを証明できる必要があります。
2つの組み合わせのようなものを検討しましたか？
1時間に1回、料金を計算し、その料金を構成するすべてのものを書き込み専用テーブルに記録します。次に、月に1回（またはどれだけ長く）、そのデータから請求書を生成できます。論争や不一致がある場合は、比較的簡単に追跡できるはずです。
これは、オプションAで得られるような良好なログの代わりにはなりません。