数据库中的数据与应用程序设计的重复

Question

我有一个关于在某些情况下处理数据集的应用程序设计问题。

假设我有一个使用某些实体的应用程序。我们有一个订单，包含有关客户，截止日期等的信息。然后我们有一个服务实体与订单有一对多的关系。服务包含它的名称。除此之外，我们还有一个规则实体，它设定了一些关于从物料库存中扣除的规则。它与服务实体有一对多的关系。

现在，我的问题是：如何处理情况，当我创建一个Order时，我将它持久化到数据库，与它的关系，但同时，我不希望对发生的实体进行更改与生成的订单可见的关系。我需要将Order和与之关联的数据视为某种日志，以便从表中删除服务或更改一组规则，并不会更改已生成的订单，服务和规则。这个过程。

通常，我将如何处理，将复制服务和规则，并将其插入新表，以便数据独立于订单生成期间使用的数据。订单只会指向重复的数据，而不是原始数据，这将解决我的问题。但这是数据重复，而且我认为，这不是最好的方法。

所以，如果你理解我的问题，你知道解决这类问题的任何更好的想法吗？如果我写的内容没有任何意义，我很抱歉。告诉我，我会尝试以更好的方式表达自己。

Answer 1

我心不在焉地看着同样的情况，所以我想分享一些想法。

我们的想法是将需要版本控制的每个实体视为对象并存储在数据库对象的实例中。比方说，对于service实体，这可以表示为：

1. service表，仅包含service_id列，PrimaryKey;
2. service_state（或..._instance）表，其中包含：
   • service_id，service.service_id的外键;
   • state_start_dt，此状态变为活动状态的时刻NOT NULL;
   • state_end_dt，这个状态已经过时的时刻，NULL能够;
   • service;
   的所有真实属性
   • 主键为service_id + state_start_dt。
3. 当然，state_start_dt::state_end_dt范围不能重叠，应该受到约束。

这种做法有什么好处？

1. 您拥有基本对象的状态转换的完整历史记录;
2. 您可以按照给定时间点查询系统;
3. 可以通过插入带有所需state_start_dt戳记的适当记录来提前完成新配置的交付;
4. 更改审核已集成到设计中（嗯，comlpete跟踪需要几个额外的列）。

怎么了？

1. 会有数据重复。要减少它，请确保拆分实例化关系。例如：不要为客户数据创建单个表，创建一组用于凭据，地址，联系人，财务信息等的表。
2. 真正的主键是service.service_id，而信息保存在从属表service_state中。当service存在时，这会导致出现这种情况，而有人（有意或有误）删除了所有service_state条记录。
3. 很难确定将state条记录移到离线存档中的安全时间，因为只要系统中有实体引用service，就应该检查它们删除任何state记录之前的有效日期。
4. 由于＃3，不能只删除service_state中的记录。实际上，依赖state_end_dt列也是错误的，因为服务可能已经激活一段时间然后被抑制。并且在活动期间查询服务应该表示服务处于活动状态。因此，status列是必需的。

我认为，记住这种方法的缺点，这是非常好的。 虽然我想从关系模型的角度听一些评论 - 特别是关于这种设计的缺点。

Answer 2

我建议只在单独的快照表中复制数据。您当然可以在主表上使用版本控制方案，但我会质疑为减少重复数据而导致的额外复杂性有多少。我发现数据模型中的额外复杂性导致系统难以扩展。我会认为重复数据是2个邪恶中较小的一个。