Question

我正在寻找有关如何设计摘要电子邮件功能的想法。我不关心实际的业务代码；相反，我想重点关注它的要旨。

让我们用一个已知的例子来解决这个问题：文章。以下是一些重要功能的概述：

我一直在考虑以下方面：

介绍每位用户对以前包含在摘要中的文章的跟踪并过滤掉这些文章？
- 需要一个新的数据库表；
- 当表包含数百万行时可能会变得昂贵；
- 摘要中包含多种类型的模型时该怎么办？多个跟踪表？多态表？ ...？
使用文章创建日期来包括当前日期和所选摘要频率之间的文章吗？
- 使用数据库中已经存在的当前日期和信息，因此不需要新表；
- 当用户从每日电子邮件更改为每周电子邮件时，会发生什么？他可以在每周摘要中再次收到同一篇文章。应该考虑这种情况吗？如果是，该如何缓解？
- 由于某种原因，文章的创建日期被更新为今天，因此肯定会再次触发日期比较。应该考虑这种情况吗？如果是，该如何缓解？

或者您能想到实现此功能的其他方法吗？

我很想学习您的见识。

Answer 1

您可以制作一个附加表，其中包含每个用户的摘要订阅信息。由于邮件是一个单独的逻辑模块，因此这种方法可以使数据库设计更简洁，更通用。除此之外，附加表还提供了将来轻松扩展有关摘要订阅的存储数据的功能。例如：

借助此表的帮助，您可以轻松管理数据。例如，您可以选择每日摘要的所有收件人：

SELECT *
FROM digest_subscription
WHERE interval_type = 'daily'
  AND last_date_distribution <= NOW()

或选择每周摘要的所有收件人

SELECT *
FROM digest_subscription
WHERE interval_type = 'weekly'
  AND last_date_distribution <= NOW() - INTERVAL 7 DAY

按时间间隔类型进行条件处理，并根据规则“等于或小于”比较上次日期分配，可以避免电子邮件发送不及时的问题（例如服务器上的技术故障等）

此外，您可以使用上次数据分发的帮助信息来制作正确的文章列表。最后一次数据分配的使用可以避免间隔更改的问题。例如：

SELECT *
FROM articles
WHERE created_at >= <the last date distribution of the user>

当然，您不能避免创建日期更新的问题。但是您应该最小化发生这种情况的原因。例如，您的代码可以更新修改日期，但您的代码不应修改创建日期。