私は、（私が見ているように）ベストプラクティスを採用するか、それとも便宜を図るかについて悩んでいます。私が現在取り組んでいるアプリケーションは、ユーザーが互いに交換する「トークン」のシステムによって支えられています。これらのトークンは、(固定サイズの)「ユニット」としてグループ化できます。
元のスキーマ
これを表すために最初に作成したデータ モデルは、各「トークン」を個別に追跡し、その動きをそれぞれ記録しました。その結果、一意のアイテム、その履歴、履歴イベント タイプ、ユニット、およびユニット メンバーシップ (履歴を含む) を表す多数のテーブルを含むスキーマが作成されます。したがって、各メンバーシップ レコードは各トークンのエントリ/終了時間を追跡します。
元のモデルは包括的であり、多くの分析範囲を提供しますが、それぞれが多数のテーブルに結合し、クエリに頼るため、クエリ (ユーザーが合計で持っているトークンの数を決定する - 履歴を考慮に入れるなど) が特に複雑になります。メカニズムのようなCOUNT()。
別
トークンが個別に追跡されない場合、モデルは大幅に簡素化できます。このシナリオでは、履歴を追跡するテーブルを、各ユーザーに対して数値を記録する単一のバランス テーブルに折りたたむことができます (たとえば、「xにはn 個のトークンがあります」)。同様に、ユニット間の移動はデータ モデル内で追跡する必要はなく、常に固定サイズであるため、個別にモデル化する必要はなく、必要に応じて生成することができます (例:ユーザーの残高から 2 トークンを取得し、それをユニットと呼びます - 固定ユニット サイズが 2 であると仮定します)。
もちろん、欠点は、詳細な追跡データを分析する能力が失われることです。これに対して私が思いついた最善の解決策は、(メッセージの種類に応じて) 固定形式で詳細なアプリケーション ログを記録することです。この形式は、解析して (必要に応じて) 別のデータベースにダンプするか、ファイルに保存して保存することができます。どこかに保管されています。
残念ながら、ここでの最大の注意点は時間です。ベスト プラクティスの観点からは、元のより詳細なモデルの方が優れていると思います (これが私が最初に選択した理由です) が、時間の制約 (コンテキスト: スタートアップ ビジネス) により、簡略化されたモデルとログのオプションに向きを変えました。
誰でも洞察を提供できますか？
ありがとう！
編集：スケーラビリティについて思い出させてくれた以下のThiloに感謝します-単純化されたスキーマを支持するもう1つのポイント（最初に質問を書いたときに言及するのを忘れていましたが、ディスクスペースが私の懸念でした-アプリケーションの使用が増加し始めた後）上）。