Bra*_*ore 5 database-design relational-database
事实上，所有 POS 系统都会在销售时将商品的价格直接记录到交易表中，因为该价格可能会在以后发生变化，但其销售价格应保持不变。
我想知道如何设置保留价格变化历史记录的定价表，以便您可以根据商品及其销售时间将交易与该表关联起来，以获得正确的价格？
我认为任何曾经使用过 POS 系统的人都会理解我在这里所说的内容，但如果我的问题不清楚，请告诉我，我会尽力解释得更好。
我没有标记特定数据库，因为这个问题显然不是特定于特定数据库的，但因为我知道这是我会被问到的第一个问题：SQL Server 2008。
编辑：
这是我刚刚想到的一个解决方案，我很想得到一些反馈......
我想我可以有一个包含如下字段的价格表：PriceId、ItemId、Price、Date
PriceId 将是一个自动编号，而 ItemId 与 Items 表相关。现在，我不会将实际价格保存到交易表中，而是保存给定商品的最新 PriceId。
想法？
我真的不明白这样做的理由。您为几乎所有分析目的和大多数查询添加了额外的联接，这将影响应用程序的速度。
回答您的问题，最简单的事情是创建定价表，就像创建临时数据库一样。
因此，做出一些假设，您的定价表可能包含以下列：
id int, pk
product_id, fk into products
price_start_date date
price_end_date date
price number(x, 2)
假设您的“订单”表具有订单下达/发布的日期等，无论您使用什么来确定价格，每个确定价格的查询都会变成
select price
from pricing p
join orders o
on o.order_Date between p.price_start_date and p.price_end_date
然而，正如我所说，我不会这样做。我能想到的，将历史价格放在订单表中而不是单独的表中的唯一障碍是，它使数据库上的历史价格分析稍微重一些。如果您不想知道已售出多少件商品，那么您不会经常这样做，因此无论如何都需要使用订单表，所以我认为这不会产生很大的差异。
我认为这是一个稍微非规范化的数据库绝对是积极的而不是消极的情况之一。
好的，关于您的编辑，与我的建议几乎没有什么区别。我将假设您的表在itemid 和 date上是唯一的（不要使用它作为实际的列名称），否则日期可以在您的“items”表中同样保存得很好。
但是，这确实意味着每当您向交易表添加某些内容时，您都必须使用聚合查询来计算出每个项目的最新价格。我的建议是让更新价格变得更加困难，但计算价格却更容易。当您计算商品价格的频率高于更新价格时，我个人会按照我建议的那样对性能造成影响。