如何在 Rails 3.1 中设计事件系统
我正在 Rails 内构建类似 Facebook 墙的东西。它看起来像这样：
- Stacey S. 想成为朋友
- 您已受邀参加夏季社交活动
- Pat 回复您的消息：嘿！！！
- 美国宠物协会发布了新帖子：爱你的猫！
有两种方法可以做到这一点。我可以将每个不同的事件在创建时写入事件数据库，或者我可以从关系、邀请、收件箱和帖子表中提取并动态创建事件。
我倾向于事件数据库方法，因为只调用一个表比调用所有其他表然后正确对它们进行排序似乎更干净。你会这样做吗？
I'm building something like Facebooks Wall inside of Rails. It will look something like this:
- Stacey S. Wants to be Friends
- You've been invited to the Summer Social
- Pat Replied to your Message: Hey!!!
- American Pet Society has a new Post: Love Your Cat!
There are two ways to do this. I could have each of these different events write to the events database when they are created or I could pull from the relationships, invitation, inbox and posts tables and create the events on the fly.
I'm leaning towards the events database approach because it seems cleaner to just call that one table than all the other tables and then sort them correctly. Is this how you would do it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我现在正在构建一个具有类似要求的系统，我想您会发现后一种方法的性能特征使其极其站不住脚。根据您打算从系统中获得多少使用量，您可能会发现事件表在请求期间也会占用性能。我正在做的是使用一个基本上是具有事件源的 CQS 架构，该架构在后台为给定用户构建提要，并以完全非规范化的方式缓存它们，以使请求周期非常短。
您应该考虑的另一种方法是使用 Chronologic：https://github.com/gowalla/chronologic。它可能会为您节省不少精力。
I'm building a system with similar requirements now, and I think you'll find that the performance characteristics of the latter approach make it extremely untenable. depending on how much usage you intend to get out of the system, you may find the event table to be a performance hog during the request as well. What I'm doing is using an architecture that's basically CQS with event sourcing which builds the feeds for a given user in the background and caches them in a thoroughly denormalized fashion to make the request cycle very short.
Another approach you should look at is using Chronologic: https://github.com/gowalla/chronologic. It may save you quite a bit of effort.
无论如何，它将使您免于大量复杂的查询和排序。采用事件表方法。
By all means, it will save you from a lot of complicated queries and sorting. Go for the event table approach.