私は Stack Overflow を再作成しようとしているわけではなく、同様の質問を見ましたが、多くの回答がありません。
さまざまな種類のアクションとそのポイント数を取得するために、レールアプリ、特にモデルとその関連付けを設計する方法に興味があります。さらに、これらのポイントは時間の経過とともに減衰し、追跡している他のアクションまたは他のデータの形で修正される可能性があります。
たとえば、私が Stack Overflow を設計していた場合 (これもそうではありません)、次のようになります。
- 質問を作成する = 5 ポイント
- 質問に答える = 10 ポイント
- 選択された正解は、[質問に答える] のポイントに x2 修飾子です。
デザインの観点からは、キーパーツに 3 つのモデルが必要なように思えます。
アクションモデルはポリモーフィックであるため、質問、回答などに属することができます。関連の種類は type フィールドに格納されます。また、次に説明するポイント モデルのルックアップによって作成時に計算されるポイント フィールドも含まれます。また、ここでは説明しませんが、ユーザー モデルの合計ポイントも更新する必要があります。
ポイントモデルは、アクションがポイントを把握するためのルックアップ テーブルです。アクション タイプをキーとして使用します。また、ポイントの数とその減衰用のフィールドも格納します。
モディファイヤモデルは、どうすればよいかわからないモデルです。アクションの type フィールドを使用するポイントのように、おそらくルックアップ テーブルであるべきだと思います。さらに、いつ適用する必要があるかについて、何らかの条件が必要です。条件文の保存方法がわかりません。また、ポイントがどのように変更されたかを保存する必要があります。たとえば、x2、+5、-10、/100 などです。もう 1 つの問題は、アクションが既に発生した後に修飾子がどのように適用されるかです。私の例では、質問が回答済みとして選択されたときです。この時点で、ポイントはすでに設定されていました。私が考えることができる唯一の方法は、修飾子テーブルをチェックしてそれらを適用する修飾子になる可能性のあるすべてのモデルに after_save を設定することです。それはどういうわけか私には間違っているようです。
腐敗の処理方法など、他にも問題があります。全員のポイントを再計算するだけの cron ジョブが必要だと思いますが、うまくスケーリングできないようです。
私がこれを考えすぎているのか、それとも何なのかはわかりませんが、フィードバックが欲しいです。