关于Activity模型/表的设计问题

发布于 2024-10-11 13:51:21 字数 502 浏览 1 评论 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

来，如果应用程序/网站非常受欢迎，这是否会在某些方面影响数据库性能？我担心这个表会很快地为每个观看歌曲的用户填充。我情不自禁地观看 YouTube 上的视频，每个视频的观看次数约为 100k ++。

我应该担心吗？或者这一切都是为了添加索引并确保数据库可以在内存和磁盘空间方面进行扩展？

原文

I have got an activity model which keeps track of each users activity. In this model I've got the following columns: id, user_id, media_id, type, created_at, updated_at

One activity I am particularly concerned about is the song view. For example. When a user clicks on a song, the song starts playing. At the same time this happens, my app creates an activity for this, each time the user views the song page.

This means I could keep a sort of history time-line for user activities. i.e.

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

In the future, if the app/site gains a lot of popularity, will this in some ways affect the database performance? I am worried that this table will populate itself very fast just for each user that views a song. I can't help looking at the videos on youtube which has around 100k ++ views per video.

Should I be worried? Or is it all about adding indexes and making sure the db can scale in terms of memory and disk space?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

还如梦归 2024-10-18 13:51:21

我认为活动模型做得太多了，因为您还存储了永远不需要的数据。

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

我省略了类型，因为这应该在 media_id 的上下文中。

如果每个视图确实获得了很多点击，那么简单的数据库将无法处理此问题。即使是 devent 数据库集群也可能存在这样的问题。但我实际上不会在早期阶段担心这些事情。

I think the activity model does too much since you also store data, that is never needed.

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

I'm omitting the type since this should be in context of media_id

If you realy get many hits per view, a simple database would not be able to handle this. Even a devent database cluster might have problems with that. But I would not actually worry about these things at an early stage.

回复收藏 0 原文

~没有更多了~