【问题标题】:Storing Email Unsubscriptions to DB将电子邮件取消订阅存储到数据库
【发布时间】:2015-01-31 15:42:07
【问题描述】:

我正在开发一种定期向注册客户发送电子邮件的产品,我想从这些电子邮件中实现某种取消订阅机制。

大约有 5 种类型的电子邮件和一个包含所有用户的 User MySql 表。新用户默认订阅所有邮件类型,并且可以单独取消订阅每个邮件类型。

我的问题是我应该如何将这些取消订阅存储到数据库,同时保持高性能和可扩展性,而不会使事情过于复杂。这里有几个选项,每个选项都有自己的优点和缺点:

  1. User 表中为每个报告类型添加一个布尔列,默认值为 true。
  2. 创建一个与User一对一 关系的新Unsubscription 表。每种电子邮件类型都会得到一列,每个用户都会得到一行。
  3. 创建一个与User 表具有多对一 关系的新Unsubscription 表。每个退订请求都会在表格上创建一个新行。

是否有存储退订信息的最佳做法?什么是数据库设计问题?

【问题讨论】:

  • 为什么需要存储退订?你不能从用户那里删除适当的订阅吗?
  • @Anentropic 默认情况下,每个用户都订阅了所有电子邮件类型,所以我认为只保存取消订阅更有意义。此外,在添加电子邮件类型时,无需更改任何数据。

标签: mysql django database-design user-accounts


【解决方案1】:

选项 3. 就 db 架构而言是最“标准化”的,这意味着可以添加电子邮件类型而无需在 db 上进行任何迁移...如果您已经有一个用于存储的表,这也是最自然的选择电子邮件类型

但是,如果您添加新的电子邮件类型,您将获得更好的性能。(没有JOINs)但代价是需要进行数据库迁移

选项 2. 似乎具有 1 的不灵活性。虽然仍然需要一个单独的表,所以这将是我最不喜欢的选项

需要考虑的其他几个选项:

  • 而不是模型上的几个布尔字段(选项 1。)使用单个 BitField https://github.com/disqus/django-bitfield 来表示取消订阅...这样做的好处是您可以添加新的电子邮件类型而无需迁移,加上查询一样快。删除类型你必须小心

  • 如上所述,如果您已经有EmailType 的表,那么在User 模型上建立多对多关系是有意义的。但是您可以使用django-denorm 自动更新模型上的BitField,这可能会两全其美

【讨论】:

  • BitField 选项看起来非常好。我想我会去的。谢谢!
猜你喜欢
  • 2011-10-10
  • 1970-01-01
  • 1970-01-01
  • 2022-01-21
  • 1970-01-01
  • 2016-03-28
  • 2019-08-04
  • 2012-12-02
  • 1970-01-01
相关资源
最近更新 更多