初めてDBモデルを自分で作成しようとしているアプリプログラマーからの別の質問。
私のアプリには、ユーザー、アカウント、トランザクションがあります。私は最初、すべてのテーブルを3NFで持っていました（またはそう信じています）。次に、ユーザーにバランスフィールドを追加することにしました。これは主に、コードがオープンソースになり、PHPコードを変更してシステムのビジネスロジックを台無しにしたくないためです。したがって、トリガーとストアドプロシージャは、バランスを更新します。
これで、ユーザーがアカウントページに、残高列で行ったすべてのトランザクションのリストを表示するという新しい要件があります。これにより、ユーザーは、トランザクションごとに残高がどのように変化するかを確認できます。もちろん、トランザクションとユーザーは異なるテーブルにあります。
それについてどうやって行くのですか？私の現在のソリューションスケッチでは、transaction_idとuser_idへの外部キーを持つbalance_historyテーブルが表示されます。他に何か提案はありますか？ありがとう。
トランザクションテーブルがそれほど大きくない場合は、usersテーブルから残高列を削除することをお勧めします。すでにトランザクションテーブルがあるのに、なぜbalance_historyなのですか？そして、トリガーからビジネスロジックを削除することを強くお勧めします！ストアドプロシージャのみ。トリガーは、真の透過的な操作（監査、複雑な検証など）にのみ使用することをお勧めします。要約すると、ユーザーテーブルから残高列を削除し、代わりにユーザーとトランザクションテーブルを結合するビュー（たとえば「UserBalance」）を作成する必要があると思います。トリガーからbussinesロジックを削除し、代わりに適切なストアドプロシージャを呼び出します。残高履歴を表示するには、トランザクションテーブルのみを使用してください。これは、それほど大きくないテーブルにも当てはまります（300万から400万のレコードで問題ありません）。非常に大きなデータベースの場合は、分散キャッシュ、垂直データベースなどを使用する必要があります。
計算値をデータベースに保存すると、常にエラーが発生する可能性があります。そうは言っても、これは単なるキャッシング手法であり、キャッシュは今ではかなりよく理解されています。
ただし、アカウントページにアクセスするたびに、アカウントページで現在の残高を計算するだけの費用はかかりますか？ここでは、足し算と引き算について話しているだけです。おそらく、キャッシュされた最終的な残高を取得し、それから各トランザクションの実行中の残高を逆算するだけで可能であり、提案されたbalance_historyテーブルを維持するための多くの作業を節約できます。
また、古いトランザクションの挿入または更新が許可されている場合、balance_historyテーブルを更新するのは面倒です。次に、そのユーザーの連続する各トランザクションを更新して、現在の残高を修正する必要があります。
実行中の残高にビューを使用するというAlexeySviridovの提案は良いものですが、作成するのは難しい場合があります（特に効率的に実行するため）。Oracleの分析関数はそのようなものには本当に優れていますが、MySQLに同等のものがあるかどうかはわかりません。