如何在产品数据库中存储产品和定价历史？

Question

在数据库中存储有关产品和定价的历史信息的最佳方法是什么？

我们的供应商向我们提供各种格式的目录，这些目录通常包含

• 制造商的产品ID，
• 产品名称，
• GTIN-13，
• 和管理系统更新项目。

基于这些信息，我想创建一个产品数据库

• 我的产品ID，
• 我的产品名，
• 产品的制造商，
• 产品的供应商，
• 制造商的产品ID，
• 产品的制造商名称，
• GTIN-13，
• 管理系统更新项目，
• 购置成本，
• 我的顾客的大宗价格，
• 当然还有我的顾客的零售价。

除了，我还想存储有关定价和产品的历史信息。

首先，价格显然发生了变化。我想在进口新产品时保留有关当前价格的信息。每个价格(管理系统更新，收购，散装，零售)可以独立变化，零售甚至手动调整，以适应市场条件。

第二，微小的产品变化。制造商将定期发布旧产品的新版本，但对制造商的ID、产品名称和GTIN-13略有更改。遗憾的是，新旧版本可以共存一段时间，区别于制造商的ID。我想在同一个my_ID下保留有关产品更改的信息(旧制造商的ID、名称、GTIN-13、MSRP、采购成本)。

最后，主要产品变化。偶尔，制造商会发布全新的产品来取代一些旧的产品。而且不一定是1:1，甚至共存很长时间。可以将单个新产品设置为替换多个当前携带的产品，多个新产品可以替换单个当前携带的产品。我想要一些这方面的家谱。

在这里，什么是明智的数据(基)结构选择？理想情况下，可以由PostgreSQL支持的东西。

我正在考虑为当前信息创建一个表，并为事件源提供另一个表以保持更改。在这样的情况下，我会简单地交换来自同一my_ID下供应商的新信息。这是适当的，还是将来我会认为这是一个痛苦的错误？对于主要的产品变更，我应该做些什么？

Answer 1

我会选择保留当前表的原样，并添加一个表来保存定价历史记录，这些历史记录通过您的产品id与带有时间戳相关，并且每天都要将今天的定价快照放到历史记录中。

您可能想进一步考虑一下，业务查询可能会出现在与定价历史有关的问题上。在脑海中浮现的一个例子是追踪促销是否有效，因此也就是价格的原因。

也有可能需要跟踪销售数量每天，这样你可以显示每周，每月，季度，每年的销售趋势。

超越一张桌子一点也不坏。您的应用程序可以提供的商业智能越多，就越好。

Answer 2

保持相同的结构，除非将定价数据提取到一个单独的表中。该表将共享item表的主键，但它将为生效日期添加一个日期时间字段。您可以获得旧价格的完整历史以及它们何时生效，并且可以通过查找与给定项目与最近生效日期相匹配的记录来轻松查询当前价格。

我知道这是可行的，因为我使用过几次类似的系统，而且它们都使用了相同的模型。效果很好。