用户、事件和事件列表的数据库结构

Question

我正在创建一个用于管理事件的 Web 服务。该服务将拥有列在一个名为“用户”的数据库中的用户。它还具有在另一个称为事件的数据库中列出的事件。

每个事件都会有一个受邀用户列表，该列表的长度是可变的。每个受邀用户都有各种属性，包括他们是否接受了邀请，以及他们是否参加了。

我打算使用 SQL 数据库；SQLite、MySQL 或 PostgreSQL。但是，如果有人建议，这可以改变。

我的问题是我应该如何存储每个事件的受邀用户信息？要求是：

1. 我可以同样轻松地查找受邀参加活动的用户和邀请用户参加的活动。

2. 该解决方案是可扩展的，即如果我最终拥有数百万用户和数百万事件，那么该方法可以应对。请注意，每个活动只会有少量客人，例如 2-1000。

3. 该解决方案在访问时间、计算资源和存储要求方面是高效的。

我想到的一些选择：

1. 对于每个事件来宾列表，将用户 ID 和其他属性作为 blob 或每个属性的 blob 存储在事件数据库中。这里的问题是客人的数量各不相同。固定长度意味着浪费空间或限制最大来宾长度大小。此外，这种方法不允许快速查找用户受邀参加的活动。

2. 对于每个用户，将他们受邀参加的事件列表以及其他属性存储为用户数据库中的 blob。同样，问题在于事件的数量不同，并且这种方法不允许快速查找受邀参加事件的用户。

3. 1 和 2 的组合。这引入了冗余，以及在保持两个数据库同步时发生错误的可能性。

4. 每个事件用户列表的单独 SQLite 数据库。我怀疑这在存储和计算上都非常低效。此外，它不允许轻松计算邀请用户的事件。

5. 另一个存储用户事件项目的数据库，每个用户被邀请参加每个事件。这必须允许按用户或事件进行快速过滤。我是数据库的新手，所以不知道这是否可以在 SQL 数据库中实现，或者需要其他类型，如果可以，是什么。

非常感谢您对这些选项的评论以及任何进一步的建议。

Answer 1

根据您上面的评论，当您说所有内容都存储在单独的“数据库”中时，您实际上是想说“表”。我将按照这个假设工作......

我建议使用一个简单的表格来存储谁被邀请参加哪个活动，以及他们的反应是什么。

请柬
-----------
  id（表的主键）
  user_ID（users.ID 的外键）
  event_ID（events.ID 的外键）
  响应（可以是一个简单的字符串，也可以是可能响应表的 ID，例如“出席”、“未出席”、“不确定”……）
  date_sent（发送邀请的日期）
  response_by_date（用户必须响应的日期）
  mode_sent（是通过电子邮件、短信、其他电子消息、普通邮件、信号量标志等发送的邀请...）

上述结构将跟踪哪个用户被邀请参加哪个事件。它还将跟踪用户的响应。诸如此类的其他字段date_sent不是必需的，但可用于其他目的。用于此的数据可能如下所示：

请柬
-----------
身份证 | 用户 ID | event_id | 回复 | date_sent | 响应日期 | 发送模式
-------------------------------------------------- ---------------------
1 | 123 | 5 | 参加| 2014-12-01 | 2014-12-05 | 电子邮件
2 | 第456话 5 | 不注意| 2014-12-01 | 2014-12-05 | 电子邮件
3 | 第456话 7 | 参加+1 | 2015-01-01 | 2014-12-02 | 信号量标志

（这里假设用户和事件表已经存在）

这对你的目的有用吗？