我正在创建一个用于管理事件的 Web 服务。该服务将拥有用户，这些用户列在一个名为“用户”的数据库中。它还将有事件，这些事件列在另一个数据库中，称为事件。
每个事件都会有一个受邀用户列表，其长度是可变的。每个受邀用户都有不同的属性，包括他们是否接受了邀请，以及他们是否参加了。
我打算使用 SQL 数据库；SQLite、MySQL 或 PostgreSQL。但是，如果有人建议，这可能会改变。
我的问题是我应该如何存储每个事件的受邀用户信息？要求是：
我可以同样轻松地查找受邀参加活动的用户和受邀参加的活动。
该解决方案是可扩展的，即如果我最终拥有数百万用户和数百万事件，那么该方法可以应对。请注意，每个活动只会有少量客人，例如 2-1000。
该解决方案在访问时间、计算资源和存储要求方面都很高效。
我想到的一些选择：
对于每个事件来宾列表，将用户 ID 和其他属性作为 blob 或每个属性的 blob 存储在事件数据库中。这里的问题是客人的数量各不相同。固定长度意味着浪费空间或限制最大访客长度大小。此外，这种方法不允许快速查找邀请用户参加的活动。
对于每个用户，将他们受邀参加的事件列表以及其他属性存储为用户数据库中的 blob。同样，问题在于事件的数量各不相同，并且这种方法不允许快速查找受邀参加事件的用户。
1 和 2 的组合。这引入了冗余，以及在保持两个数据库同步时发生错误的可能性。
每个事件用户列表的单独 SQLite 数据库。我怀疑这在存储和计算方面都非常低效。此外，它也不允许轻松计算邀请用户的事件。
另一个存储用户事件项目的数据库，每个用户受邀参加每个事件。这必须允许按用户或事件进行快速过滤。我是数据库新手，所以不知道这是否可以在 SQL 数据库中实现，或者需要其他类型，如果可以，是什么。
我们非常感激收到对这些选项的评论以及任何进一步的建议。