一个Web系统，信息表存放有大量的记录，比如500W条，用户可以按类别订阅其中的一些信息，每个用户订阅的信息，可以标记哪些信息该用户已读，哪些未读。为了能实现某用户订阅了哪些信息，其中哪些信息该用户已读，哪些未读，在数据库设计上，一般做法是信息表 Info
InfoID,Info,...用户表 User
UserID,UserName,...用户订阅的信息 Subscibe
InfoID,UserID,isRead,...
假设当前用户数10W，平均每个用户已经订阅的信息记录数是5000，而用户数还在不断增长，平均订阅的记录数也可能在不断增长，按当前的数据，Subscibe就已经有5亿条记录了，而以后这个数据还会不断的增大。这么庞大的数据量，光是但用户使用的时候数据库检索速度应该难以忍受了，正常情况下多用户并发使用的时候，其结果可想而知。想要问的问题是：对于这样的应用，可有什么好的解决方案？数据库方面，还有别的设计方案吗？
InfoID,Info,...用户表 User
UserID,UserName,...用户订阅的信息 Subscibe
InfoID,UserID,isRead,...
假设当前用户数10W，平均每个用户已经订阅的信息记录数是5000，而用户数还在不断增长，平均订阅的记录数也可能在不断增长，按当前的数据，Subscibe就已经有5亿条记录了，而以后这个数据还会不断的增大。这么庞大的数据量，光是但用户使用的时候数据库检索速度应该难以忍受了，正常情况下多用户并发使用的时候，其结果可想而知。想要问的问题是：对于这样的应用，可有什么好的解决方案？数据库方面，还有别的设计方案吗？
不过这点数据量Oracle绝对可以处理，只是考虑到效率的情况下采取一些改进措施。