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