数据库设计：如何处理“归档”问题？

Question

我很确定每天都有很多应用程序、关键应用程序、银行等等。

这一切背后的想法是：

• 所有行都必须有历史记录
• 所有链接必须保持连贯
• 请求获取“当前”列应该很容易
• 购买过时商品的客户仍然应该看到他们购买的商品，即使该产品不再是目录的一部分

等等。

这就是我想要做的，我将解释我面临的问题。

我所有的表都会有这些列：

• id
• id_origin
• date of creation
• start date of validity
• start end of validity

以下是 CRUD 操作的想法：

• create = 用id_origin= id, date of creation=now, start date of validity=now, end date of validity=null插入新行（= 表示它是当前活动记录）
• 更新 =
  • read = 用end date of validity==null读取所有记录
  • end date of validity用end date of validity=now更新“当前”记录=null
  • 使用新值创建一个新的，并且end date of validity=null （= 表示它是当前活动记录）
• 删除 =end date of validity用end date of validity=now更新“当前”记录=null

所以这是我的问题：多对多关联。让我们以值为例：

• 表 A (id = 1, id_origin = 1, start=now, end=null)
• 表 A_B（开始=现在，结束=空，id_A = 1，id_B = 48）
• 表 B (id = 48, id_origin = 48, start=now, end=null)

现在我要更新表A，记录id=1

• 我用 end=now 标记记录 id=1

• 我在表 A 中插入一个新值......该死的我已经失去了我的关系 A_B除非我也复制关系......这将结束一个表：

• 表A（id=1，id_origin=1，start=now，end=now+8mn）

• 表A（id=2，id_origin=1，start=now+8mn，end=null）
• 表 A_B（开始=现在，结束=空，id_A = 1，id_B = 48）
• 表 A_B（开始=现在，结束=空，id_A = 2，id_B = 48）
• 表 B (id = 48, id_origin = 48, start=now, end=null)

而且...好吧，我还有另一个问题：关系 A_B：我是否应该将 (id_A = 1, id_B = 48) 标记为过时（A - id=1 已过时，但 B - 48 未过时）？

如何处理？

我必须大规模地设计：产品、合作伙伴等等。

你在这方面有什么经验？你会怎么做（你是怎么做的）？

- 编辑

我发现了这篇非常有趣的文章，但它没有正确处理“级联过时”（=我实际上在问什么）

Answer 1

我不清楚这些要求是出于审计目的还是只是简单的历史参考（例如 CRM 和购物车）。

无论哪种方式，请考虑为需要的每个主要区域建立一个 main 和 main_archive 表。“Main”将仅具有当前/活动条目，而“main_archive”将具有进入 main 的所有内容的副本。插入/更新到 main_archive 可以是插入/更新到 main 的触发器。如果有的话，对 main_archive 的删除可以运行更长的时间。

对于诸如 Cust X 购买了产品 Y 之类的引用问题，解决 cust_archive -> Product_archive 的引用问题的最简单方法是永远不要从 Product_archive 中删除条目。一般来说，该表中的流失率应该低得多，因此大小不应该成为太严重的问题。

HTH。