设计摘要电子邮件实现的方法？

Question

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

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

1. 用户可以选择，选择，文摘频率(例如，每日或每周)；
2. 摘要仅包含新的文章；
3. “新文章”将被视为相对于发送给特定用户的前一个摘要的；

我一直在想以下几点：

• 介绍以前包含在摘要中的文章的每个用户跟踪，并过滤掉那些？。
  • 需要一个新的数据库表；
  • 当表包含数百万行时，可能会变得昂贵；
  • 如果在摘要中包含多种类型的模型，该怎么办？多个追踪表？多态表？

​

• 使用文章创建日期包括当前日期与所选摘要频率之间的文章？
  • 使用数据库中已经存在的当前日期和信息，因此不需要新的表；
  • 当用户从每日邮件更改为每周邮件时，会发生什么？他可以在每周的文摘中再次收到同一篇文章。我们是否应该考虑这个边缘问题呢？如果是的话，如何减轻呢？
  • 由于某种原因，文章的创建日期被更新到今天，再次触发日期比较。我们是否应该考虑这个边缘问题呢？如果是的话，如何减轻呢？

​

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

我很想了解你的见解。

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>

当然，您不能避免更新创建日期的问题。但你应该把发生这种事的原因降到最低。例如，您的代码可以更新修改日期，但是您的代码不应该修改创建日期。