Question

基本上，我的问题是 - 我有一份价格清单，其中一些是历史价格（即我希望能够搜索产品X在3月11日为0.99美元，4月1日为1.99美元等等）。存储此信息的最佳方法是什么？

我假设我可能有一个Product表，它有一个价格表的外键。我最初认为存储当前价格可能是最好的选择，但我认为我希望能够存储历史价格数据，因此更好的方法是在价目表中存储如下表格： / p>

CREATE TABLE prices (
         id BIGINT auto_increment not null,
         primary key (id),
         price DECIMAL(4,2) not null,
         effectiveStartDate DATETIME NOT NULL,
         effectiveEndDate DATETIME 
);

我在这里有点不知所措。我希望能够有效地搜索产品，并了解该产品的价格如何随时间而变化。如何有效地将一组这些价格与产品相关联？我想我要问的是，'为了能够为跨越特定日期的查询提供有效搜索，最好的方法是将其编入索引？'

Answer 1

将历史数据的需求与当前价格的需求分开。这意味着：

1）将当前价格保留在产品表中。

2）当价格发生变化时，将新价格插入历史表中，仅包含开始日期。您实际上并不需要结束日期，因为您可以从上一行获取结束日期。（您仍然可以将其放入，这使查询更容易）

另请记住，您的订单历史记录提供了另一种历史记录，即以给定价格随时间推移的实际购买量。

Answer 2

首先，确保您真的需要这样做。您是否在同一个数据库中存储订单？如果是这样，您可以随时通过检查订单中物品的价格来查看历史价格趋势。这样您还可以在价格变化和订购模式变化之间建立关联;它无法解决的唯一情况是，如果价格变化导致没有订单被放置。

话虽这么说，如果你想要一个独立的价格变化记录，你所呈现的是好的。我唯一建议的是取消结束日期;除非您计划在产品 no 价格或价格重叠的情况下产生时间差，否则开始日期就足够了，这将使您的逻辑变得更容易。

Answer 3

对于更复杂的系统，结束日期可能是可行的，您可以在此系统中计划产品价格（即各种季节性促销/等）。（哦，这是BS，应该考虑更多...好吧，只有当你同时计划多个产品价格时才需要结束日期，区别于其他东西......仍然通常很方便将它放在里面当前记录，不看上一个/下一个）

实际上，对于大多数复杂系统而言，通过“维度”区分几种当前价格并不罕见（即某种属性可能由实际运输地点或客户所在国家等决定......）

我还会检查你的平台/语言/框架/工作方式的两倍，然后省略自定义“id”主键，转而使用[product_id，starting_date，..？..] composite pk。后者在某种程度上更合乎逻辑（至少我个人更喜欢它），但它有时可能会适得其反，例如，如果你的数据库只有有限的方式来处理更复杂的主键。

在MySQL表中存储历史价格表的最佳方法是什么？

3 个答案: