我正在开发一个群发电子邮件应用程序，理论上可以每周发送许多广告系列，每个广告系列都会向成千上万的联系人发送。
我已经设计了两种可能的方式来存储这些广告系列：
app_campaigns表和app_campaign_emails表，在引用父广告系列和实际联系人时为每封电子邮件创建一行。 app_contacts表将存储实际的电子邮件地址和其他数据。app_campaigns表中，以逗号分隔的字段存储。这样，就无需为每个广告系列创建多条记录。最好的方法是什么？在这里，性能和保持数据库较小是一个优先事项，因为一些活动可以快速增加数据库的大小（有多个客户每周发送多个活动，每个活动都有一个可能很大的联系人列表）。
但它还需要跟踪打开和点击，我正在考虑通过仅在记录条目发生时进行操作。
某些应用程序（例如Sendy）会采用第二种方法，并且无需一次创建数千行。但是，它可能会有点混乱，因为使用逗号分隔的Id字段进行搜索和查询比查询数据库更难。
为了进一步复杂化，应该有一种方法来显示发送给CRM-esque界面中的联系人的每封电子邮件。因此，通过使用第二种方法，它意味着在app_campaigns表中进行FULLTEXT搜索以构建正确的列表。
有什么想法吗？
答案 0 :(得分：0)
存储数据的正确SQL方法是在每个表中为每个联系人创建一个单独的行。
为什么呢？以下是将数字ID存储在逗号分隔列表中的原因不是一个好主意：
即使是连接表会大得多的概念也是可疑的。考虑一百万 - 1,000,000。作为字符串，这占用7个字节，但逗号分隔符使其为8。
如果你有一个包含两个键的表，并且每个都是一个整数，那么引用表中的行就会占用 - 猜猜是什么，8个字节。
在某些情况下，可能需要保存以逗号分隔的字符串。我能想到的唯一一个是数据库根本没有使用该字符串，而是因为某种原因被传递回应用程序。换句话说，字符串本质上是BLOB＆gt;