我现在有两个独立的时事通讯数据库。一种是简单的选择加入，客户只需提供他们的电子邮件地址即可接收我们的邮件，另一种是成熟的客户帐户数据库（用户名、密码、地址、订单历史记录等）。两者最终都会得到基本相同的时事通讯（我们会尽可能地进行一些细分和动态内容）。此外，我应该提到，选择加入表有一些一次性的列，其中不同的营销计划收集了有关联系人的数据（联系人在哪里注册 [在线/离线] 以及它是什么促销活动，他们的邮寄地址，如果我们拥有它，等等）。
我已经设置了这两个列表多年，但是随着客户从简单的选择加入到创建帐户，他们更新他们的电子邮件地址等，管理变得越来越难。一旦用户创建帐户，他们将从那里管理他们的时事通讯设置是有道理的。但有时现有客户在选择加入时输入他们的电子邮件地址（反之亦然），并且管理重复项开始变得复杂。我们还必须处理两个数据库之间的大量重复数据（并且跨越多个数据库，而不仅仅是表，是一个挑战）。
更复杂的是，我们使用第三方服务发送我们的时事通讯。我们有一些经常运行的进程会执行一些双向同步，所以我每次都必须做一些杂耍来确定我从哪个数据库中提取更改/将更改推送到哪个数据库，最后更新哪个源等等。 . 如果联系人从 opt-in 列表移动到客户列表，我必须推送更改，停用旧关系；如果他们将自己添加到选择加入中并且我们已经将他们的电子邮件保存在另一个数据库中，我会设置一个标志来忽略他们——这一切都令人头疼。
现在这必须是一个非常普遍的情况。我访问的几乎每个电子商务网站都至少有两个这样的不同列表。我的问题是他们是如何处理的？最佳做法是什么？
在我看来，我有两个选择：
在同一个数据库中使用两个不同的表（这与我现在的做法非常接近）。这使我能够继续保持独立和有条理，但同时有效地检查两个列表是否存在冲突/重复信息。我仍然有许多相同的问题（移动关系或定义“主记录”、重复数据、传播更改等），但它至少应该简化一些事情。
创建一个表（称为 NewsletterContacts 或其他名称）供所有联系人共享。可能会直接添加选择加入的用户，但必须同步客户帐户表中的条目。不过，这也有许多缺点。对客户帐户表的任何更改都必须先推送到 NewsletterContacts，然后才能推送到我们的电子邮件软件。我在那个数据库中有一些非常混合的内容——一些记录会有一个地址和来源等，其他的只有一个电子邮件地址，然后其他的会指向一个客户帐户表，其中包含所有类型的其他信息.
TL,DR：当您知道会有重复时，您如何管理两个单独的时事通讯列表？