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