大量导入/导出的数据库的规范化

Question

目前，我正在开发一个事件注册系统(在php中)。它有两个主要目的:在活动开始前在线注册客人，以及使用条形码扫描仪扫描现场的客人。对于这个系统，重要的是有一个在线和离线服务器，不是所有的事件都将访问互联网。

数据库将从一个服务器导入/导出大量数据到另一个服务器并返回。除此之外，还会同时发生多个事件。

为了解释我在开发这个系统时遇到的问题，让我们假设有两个独立的事件(A和B)。在在线服务器上，客户可以注册这些事件。在某个时候，事件A将发生，所以我必须将数据库导出到离线服务器以供现场使用。同时，客人仍然可以在线注册活动B。在活动A现场，也可以登记活动A，但不能登记活动B。

事件A结束后，如果不以某种方式更改数据，则几乎不可能将脱机数据库导入联机数据库。我想，对于数据库方案，我可能有两个选择：

1. 完全规范化:有一个带有属性event_id的来宾表。所有依赖于来宾或事件的其他表将只引用来宾和/或事件的主键。
2. 在事件之间拆分表:有来宾表A_guests和B_guests。所有依赖于来宾或事件的其他表也将根据事件命名。

使用选择2(并且不改变数据)，导入和导出将非常容易，但是表的数量将增长很快。这在很大程度上是一个进退两难的问题:标准化，但在进口/出口方面有困难。或者将表拆分，使表的数量以递增的速度增长。

我是错过了一个选择，还是你认为其中一个选项是最好的选择？

Answer 1

在某个时候事件A将发生，所以我必须将数据库导出到离线服务器以供现场使用。同时，客人还可以在网上注册活动B。在活动A现场，也可以注册。

我想确定我明白这一点。在某个时候，您将数据库导出到事件A的脱机服务器。来宾不能再在线注册事件A，但只能在事件A的站点注册，这是正确的吗？如果是这样的话，只要在线软件知道出口，就不会有问题。

在活动A，你想让客人登记活动B。这是对的吗？因为，如果是这样的话，你将不得不最终将那些B事务传回你的在线数据库，我想，我想，希望你不要用2份或更多的数据库拷贝来超额预订B，你没有防止超额预订的机制。

我错过了一个选项，还是你认为这些选项中的一个是最好的选择？

你想让你的预订数据库完全正常化。如果您想让人们在活动A注册事件B、C或D等，则事件A需要拥有整个预订数据库的副本。

我看到的唯一问题是超额预订问题，因为您在各种活动中都有数据库的所有副本。