应用程序运行于ruby 2.0：rails 4和postgresql
1.多表故事——现在如何运作：
Aproject有很多users, as members。
也project有很多posts，当post创建一个时notification为每个创建一个project user。
假设项目 A有100 个用户，我们将在数据库中有100 个通知，这将加载具有大量重复项的数据库。
但是用户可以删除自己的通知，可以查看它，我们可以用用户特定的数据更新他的通知。我们将使用rake 任务来删除早于特定时间间隔的通知。
2.多个数据库查询 - 我们想要做的：
有一个想法是只为一个活动创建一个通知，并与一个名为的表使用多对多关系， ETC..notifications_users
我认为这将是多个数据库查询的缺点，因为当我们需要查找有关通知和用户的信息时，我们必须查找notification_users表以获取所需的信息。
此外，通过这种方式建立关系，将更难从旧通知中清理数据库，因为我们不知道该通知是否被某些用户读取。
谢谢你。
选项 (1.) 看起来非常合理，如果您可以保持通知模型精简——比如 user_id、activity_id、时间戳，可能还有更多标志，那么就不会期望不合理的性能损失，因为它看起来像一个非常常见的关系模型，我希望数据库能够轻松处理它。
如果您保持通知到期时间紧，这意味着通知不应该增长，或者如果它确实增长，例如当用户刚刚放弃帐户时，我会寻找问题的具体解决方案，如出现的那样。
在Assembla.com，我们通过电子邮件进行通知，这对我们来说非常有效，我想说。所以，也许在某个时候，您可能也想考虑这个选项。
在我看来，（2.）只是不能满足业务需求，如果你不考虑它们，那么它可能也不值得考虑这个选项。
在分析您的问题中给出的场景之前，我想请您澄清一点，这在您的问题中有点令人困惑。下面给出的陈述令人困惑。
1）项目也有很多帖子，当创建一个帖子时，会为每个项目用户创建一个通知。
2) 假设项目 A 有 100 个用户，我们将在数据库中有 100 个通知，这将加载具有大量重复的数据库。
声明编号 1 描述了创建帖子的时间；为每个用户发送通知。所以假设有 100 个用户和 100 个帖子，那么包含通知数据的表将有 10000 行（100*100）。
声明编号 2 描述如果有 100 个用户，那么数据库中将有 100 个通知，这意味着通知表将有 100 行。
我应该考虑以上几点。