持久化具有许多不同依赖关系的事件/对象

Question

我认为以下是一个非常常见的用例，但即使在考虑了几个小时并与朋友讨论后，我也找不到令人满意的解决方案。

基本问题：如何存储和有效查询与许多不同关系有关系的对象/实体？

对象
想象一下，你有一个系统可以跟踪一组汽车，它们的位置和它们的驱动程序（每个都是你的数据库/系统中的一个实体）。通过监控汽车的活动，您将产生诸如超速违规，两辆汽车之间的碰撞和燃料加注等事件。现在，这些事件中的每一个都有一点不同，建模为对象，它们可能具有以下属性：

超速违规

• 速度（整数）
• 汽车（参考）
• 司机（参考）

碰撞

• car1（参考）
• car2（参考）
• driver1（参考）
• driver2（参考）
• 职位（参考）
• 日期＆amp;时间
• 州（固定或新的）

燃油加注

• 汽车（参考）
• 金额（浮动）
• 职位（参考）

此外，他们都共享一些属性，如创建日期和拥有公司。也有可能在将来生成新事件，这些事件应该很容易添加到任何存储系统/模型中。

查询要求
查询大致按重要性排序（最重要的是首先）。系统应该能够有效地

• 查询给定公司或时间范围的所有通知（及其属性）
• 查询属于某个汽车或司机的所有通知
• 查询特定类型的所有通知（例如所有填充通知）

问题
如何将上述对象存储在数据库中（尽管引用的实体位于关系数据库中，但不一定是关系型的），这样可以有效地执行所描述的查询？

这里效率的定义可以非常灵活，对我来说重要的是那种情况，例如：必须避免单独查询所有依赖项。

潜在解决方案
以下是我提出的一些想法：

• 2表模型：第一个表event包含事件的公共常规信息，例如id，company，event_type和创建日期。然后，第二个表event_objects包含所有不同的附件，并包含列id，event_id，object_id和object_type。

  • 好：
    • 大多数查询都可以有效回答
    • 非常容易扩展其他活动
    • 非常容易为事件添加新属性
  • 为：
    • 当必须检索特定事件的对象时，必须使用单个查询提取每个对象
    • 如果数据库是关系型的，则这违背了良好做法/设计用途（基本上将数据库用作键值存储）

• 每个事件1个表：只需为每个事件类型创建一个表，并为每个属性添加一列

  • 好：
    • 可以非常有效地查询相同类型的事件
    • 查询公司/汽车等的所有事件只是事件类型数量的线性（与相关属性的数量乘以2表模型的获取事件数量相反）
    • 更适合关系模型
  • 为：
    • 更难以查询公司的所有事件/时间范围（需要#types查询）
    • 难以向现有事件类型添加新属性

结论
基于列出的优点和缺点，我很想使用每个事件解决方案的1个表，但它对我来说似乎仍然不是特别优雅。我相信我不是第一个遇到这个问题的人，并且很想听听别人如何处理类似的问题。