微博启动数据库
我会做微博网络服务（为了学校，所以不要因为缺乏新想法而责备我），我担心数据库可能经常超载（用户可以关注其他用户甚至标签，所以我假设 SELECT< /code> 将会很重 - 检查 20 条最新消息，其中包含所有观察标签和用户）。
我的想法是创建另一个表，并在其中仅存储 statusID 和 userID （谁应该接收消息）。危险的是，如果某个标签或用户有很多关注者，就会有很多带有该状态 ID 的记录。那么，这是个好主意吗？或者也许使用 M2M 关系更好？ （一种状态 -> 许多接收者）
I will do microblogging web service (for school, so don't blast me for lack of new idea) and I worry that DB could be often be overloaded (user could following other users or even tag so I suppouse that SELECT will be heavy - check 20 latest messages which contains all observing tags and user).
My idea is create another table, and store in it only statusID and userID (who should pick up message). Danger of that is, if some tag or user has many followers there will be a lot of record with that status ID. So, is it good idea? Or maybe better is used M2M relation? (one status -> many receivers)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为大多数数据库都可以轻松处理大型记录集。让它执行的责任在于您的设计以及正确设置索引。如果您创建了正确的索引，则 select 子句应该表现得非常好。
I think most databases can easily handle large record sets. The responsibility to have it preform lies in your design with properly setting up the indexes. If you create the right indexes the select clauses should perform really well.
我会使用用户表，该表具有用户和消息表之间的m2m关系。
然后，您可以执行一次选择来查找用户正在关注的所有用户，然后执行第二次选择来获取所有感兴趣的消息（根据需要对结果进行排序和限制）。将其扩展到标记应该非常简单。
只要您对正确的列建立索引，这种设计就应该适合大量用户和消息。如果您的规模很大，那么您还可以将用户表和消息表运行到不同的服务器或进行只读复制。我暂时不会担心这个——你需要足够大。
I'd go with a users table, a table to have the m2m relationship between users and messages table.
You can then do one select to find all of the users a user is following and then a second select in to get all of the messages of interest (sorting and limiting the results as appropriate). Extending this to tagging should be pretty simple.
This design should be fine for large numbers of users and messages as long as you index the right columns. If you got massive then you could also run the users tables and messages tables to different servers or have read only replicates. I wouldn't even worry about that for the moment - you'd need to be huge.
实施 Collabinate (http://www.collabinate.com) 时，这是一个用于微博和共享活动的基于服务的引擎流，我使用了图形数据库。人们创建帖子并关注其他人的事实本身就形成了图表结构。通过正确的关系和算法，这可能是一个非常高效且高性能的解决方案。
When implementing Collabinate (http://www.collabinate.com), a service-based engine for microblogging and shared activity streams, I used a graph database. The fact that people create posts and follow other people lends itself to a graph structure. With the right relationships and algorithms, this can be a very efficient and performant solution.