2011-01-12 5 views
0

私は各ユーザのアクティビティを追跡するアクティビティモデルを持っています。このモデルでは、id、user_id、media_id、type、created_at、updated_atという列を持っています。アクティビティモデル/テーブルの設計に関する質問

私は、特に曲の表示が心配です。例えば。ユーザーが曲をクリックすると、曲の再生が開始されます。これと同時に、私のアプリは、ユーザーが曲のページを表示するたびに、このためのアクティビティを作成します。

これは、ユーザーアクティビティに一種の履歴のタイムラインを保持できることを意味します。すなわち

Foobar listened to Song A 2 hours ago 
Foobar listened to Song A yesterday 
Foobar listened to Song B 2 days ago 
etc 

今後、アプリ/サイトの人気が高まると、これがデータベースのパフォーマンスに影響を与えますか?私は、このテーブルが曲を見ている各ユーザのために非常に速くそれ自身を移植することを心配しています。私は約100k + 1ビデオあたりのビューがあるyoutube上のビデオを見て助けることができません。

私は心配すべきですか?それとも、インデックスを追加して、データベースがメモリとディスクスペースに関して拡張できるかどうかを確認することですか?

答えて

1

あなたはデータを保存しているので、それは決して必要ではないので、アクティビティモデルがあまりにも多くなると思います。

 table 
------------------------ 
user_id  int 
media_id  int 
listened_at TIMESTAMP 

これはあなたが本当にビューごとに多くのヒットを取得した場合は、単純なデータベースは、これを処理することができませんmedia_id

のコンテキストでなければなりませんので、私は、タイプを省略しています。 deventデータベースクラスタでもに問題があります。しかし、私は実際に早い段階でこれらのことについて心配しないでしょう。

+0

私はそこに型フィールドを持っている理由。タイプは、ビュー、好き、コメントなどとなりうるからです。アクティビティモデルの目的は、すべてのタイプのユーザーインタラクションを保存することです。アクティビティモデルがあまりにも多く行っていると思われる場合は、何をお勧めしますか? :-) –

関連する問題