我有一个名为“event”的sql表和一个名为“pass\u event”的复制表。事件表有一个外键指向它对应的过去事件。鉴于：
对事件表所做的任何更新也会对过去的事件表进行更新。它们是“复制品”。
事件表的写入和读取非常频繁。
对过去的事件表的读取非常频繁。
当事件表中的事件结束时，它将从事件表中删除。因此，创建的每个事件最终将只存在于过去的\u事件表中。
我决定在过去的事件表中的事件表中复制信息，因为我的应用程序正在查找有关当前和正在进行的事件的数据（只需要从事件表中读取），或者它正在查找已结束的事件（只需要从过去的事件表中读取）。但决不能两者兼而有之。我的基本原理是，对事件的子集进行sql查询比另一种查询更快。
备选方案：
如果相反，我将两个表合并到一个名为event的表中呢。然后，我将添加一个数据库索引的布尔字段“hasend”，以便查询正在进行或已结束的事件。
上述哪种策略更有效？
更多信息（更新）：
每天都会创建许多事件。同时，由于许多事件行已结束，因此每天都要对它们进行修剪。每12小时运行一次的chron作业会从事件表中删除事件，并删除已结束的事件。
一个事件行不会产生许多过去的事件。只有一个（它将保持其对应事件行的当前状态的精确副本）。
主键是auto-inc。此外，创建事件时，会使用相同的主键id创建过去的事件，以满足我的个人需求。
1条答案
按热度按时间9q78igpj1#
“可笑”是我想到的词。出于对“效率”的某种定义的兴趣，您希望复制数据和对数据的每次修改。对我来说，这根本没有效率。
我将从软删除开始——一个简单的标志，指示事件是否被删除。这很好地定义了事件。
因为您需要的两种模式要么是全部模式，要么只是未删除的模式，所以如果需要，您可以考虑优化存储。一个选项（如果您的数据库支持）是delete标志上的聚集索引。通常不建议在二进制标志上使用这种集群。但是，如果未删除的数据很小，那么对于寻找该数据的查询来说，这可能是一个胜利。
另一种选择是使用分区。有些数据库不允许您更改分区键——这是一个挑战。
最后，你也可以有一个
delete触发器在events将已删除事件加载到另一个表中的表。对所有事件的查询都需要将它们合并在一起。