设计摘要电子邮件实施的方法？答案

【问题标题】：Ways to design a digest email implementation?设计摘要电子邮件实施的方法？
【发布时间】：2018-12-11 17:26:13
【问题描述】：

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

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

我一直在考虑以下几点：

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

或者你能想出其他方法来实现这个功能吗？

我渴望了解您的见解。

【问题讨论】：

【解决方案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>

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

【讨论】：