3

ユーザーのアクティビティがポイントで報われるアプリケーションがあります。特定のアクションに対して一定量のポイントを割り当てるポイント チャートがあります。

私の質問は、どちらのアプローチが優れているか、そして最も重要なのはなぜですか?

アプローチ 1 : - mysql で userPoints テーブルを作成し、ユーザー アクションごとにそこにポイントを挿入します。ユーザーが自分のプロファイルにアクセスしたら、データベースにポイント数を照会して表示します。

例:
ユーザーがアイテムを購入する
データベースをクエリする: ユーザー 2 の userPoints に 5 ポイントを挿入する ユーザー
が場所に従う
データベースをクエリする: ユーザー 2 の userPoints に 7 ポイントを挿入する
ユーザーがアイテムを販売
する データベースをクエリする ユーザー 2 の userPoints に -5 ポイントを挿入する

アプローチ 2 : - ポイントをテーブルに保存するのではなく、ユーザーが完了したアクションの数をカウントし (データベースからカウントとタイプを取得します)、実行時にアクションのタイプごとに一定量のポイントを掛けます。ポイント数が必要なときはいつでも（たとえば、プロフィールにアクセスしたときなど）

例：
ユーザーは自分のプロフィールにアクセスして
、データベースにクエリを実行し、所有しているアイテム、フォローされている場所、友情をカウントしてから、アイテム数x5、フォロー数x7、友情数x10を掛けて、その数を表示します

スティーブンの編集：

はっきりさせておきますが、これは私が取るべき行動の年表ですか？これを強化してクエリの数を減らすにはどうすればよいですか?

  • アイテムの購入の actionId は 1 で、報酬ポイントは 5 です (これはデータベースのアクション テーブルで指定されています)。
  • Kylie (ユーザー ID: 1) がアイテムを購入します。
  • クエリ DB: ユーザー ID1 の userItems テーブルにアイテムを追加します。
  • Query DB: userActions テーブルにアクションを登録 - userId: 1, actionId: 1
  • Query DB SET userPointsTotal = userPointsTotal + ポイントが与えられます (次のように 2 つのクエリを 1 つにネストします: set userPointsTotal = userPointsTotal + (actuionid= 1 のアクションからポイントを選択))
  • DB をクエリして userPointsTotal を取得し、Kylie のプロファイルに値を表示します
  • 将来的には、テーブル userActions を参照して、特定のタイプのアクティビティ (社会的ステータスまたは所持ステータス) に応じて、ユーザーがステータス タイトルを取得できるようにします。
4

3 に答える 3

1

保存したいもの:

  1. アクション- アクションとそれぞれに定義されたポイントをリストした表。これはドメイン テーブルとして機能します。

  2. ユーザー アクション- ユーザーが完了したアクションと付与されたポイントをリストする複合キー テーブル (user_id、action_id) (ユーザーがアクションを完了した後にアクションのポイント値が変更された場合に備えて、これをここに保存する必要があります。いつでも) SUM(user_actions.points) を実行して、ユーザーが獲得したポイントの正確な合計を取得できます。

  3. ユーザー合計- ユーザーが獲得したポイントの合計を列挙する値。これを、ユーザーのアクションを記録するときに更新する Users テーブルの列にするか、定期的に更新されるユーザー インデックスまたはキャッシュ (Solr、Memcached など) に格納されている user_actions.points の合計にすることができます。これにより、ユーザー リストを表示するたびに高価な集計関数でデータベースを処理することなく、多数の集計値を表示できます。

これにより、すべての世界で最高のものが得られます。ユーザーが獲得したポイント数を簡単に確認する方法、合計が「迷う」場合に合計を再計算するための信頼できる方法、および参照整合性/追加情報のためのドメイン テーブルがあります。

于 2013-10-26T13:18:57.487 に答える
1

ハイブリッドアプローチをお勧めします。ポイントをテーブルに厳密に保存すると、誰がどのポイントをどのような理由で持っているかを簡単に把握できなくなります。または、それらを絶えず再計算すると、ユーザーベースが拡大した場合にサーバーがすぐにダウンします. 代わりに、5 分、1 時間、12 時間ごとにポイントを再計算し、その結果を userPoints テーブルに保存すると、テーブルを検索するだけなので、アクセス速度が速くなります。また、ポイントの計算を誤ったり、ポイントの計算に使用するロジックを台無しにした場合でも、コードを簡単に修正して再計算できます。

于 2013-10-26T13:05:03.563 に答える
1

ポイントの数は、個々のアクションに基づく集計関数と考えることができるため、質問は、いつ事前集計を使用するかについての決定に要約されます。

両方のアプローチは、異なる状況下で有効です。

  • 集計の計算に必要な作業がほとんどない場合、または集計が頻繁に計算されない場合、事前集計を使用すると複雑さが増し、パフォーマンスが低下する可能性があるため、「生のイベント」を保存することをお勧めします。
  • 集計を計算するために大量のデータを処理する必要がある場合、または集計が非常に頻繁に要求される場合、事前集計はパフォーマンスを向上させる有効な方法になります。

データベースは事前集計に役立つことに注意してください。アクションテーブルでインデックスを定義し、個々のアクションではなくカウントと合計をクエリする場合 (つまり、質問のアプローチ 2 で提案した方法で実行します)、DB実際にカウントを行わずに、インデックスからのデータを使用してカウントを取得します。これにより、最初のアプローチと同様のパフォーマンスが得られ、RDBMS がほとんどの作業を行います。

于 2013-10-26T13:07:36.600 に答える