4

実質的にすべての POS システムは、販売時にアイテムの価格をトランザクション テーブルに直接記録します。これは、価格が後日変更される可能性があるためですが、販売された価格は同じままである必要があります。

価格変更の履歴を保持する価格テーブルをどのようにセットアップして、正しい価格を取得するためにアイテムと販売時間に基づいてトランザクションをそのテーブルに関連付けることができるのだろうか?

POS システムを扱ったことのある人なら、私がここで話していることを理解できると思いますが、私の質問が不明な場合はお知らせください。

この質問は明らかに特定のデータベースに固有のものではないため、特定のデータベースにタグを付けませんでしたが、それが最初に尋ねられる質問であることを知っているためです: SQL Server 2008.

編集：

これは、私が考えた1つの解決策であり、フィードバックをもらいたいと思っています...

PriceId、ItemId、Price、Date のようなフィールドを持つ価格表を作成できると考えています。

PriceId は自動採番であり、ItemId は Items テーブルに関連しています。ここで、実際の価格をトランザクション テーブルに保存する代わりに、特定のアイテムの最新の PriceId を保存します。

考え？

4

3 に答える 3

4

これを行う理由が本当にわかりません。ほとんどすべての分析目的とほとんどのクエリのために追加の結合を追加しているため、アプリケーションの速度に影響します。

あなたの質問に答えるには、テンポラル データベースを作成するかのように価格表を作成するのが最も簡単でしょう。

したがって、いくつかの仮定を行うと、価格表には次の列が含まれる可能性があります。

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

しかし、私が言うように、私はこれをしません。私が考えることができる唯一の障害は、個別のテーブルとは対照的に、過去の価格を注文テーブルに持つことで、過去の価格分析が DB でわずかに重くなることです。販売されたユニット数を知りたくないため、とにかく注文テーブルを使用する必要がなければ、これを頻繁に行うことはないので、大きな違いはないと思います。

これは、非常にわずかに非正規化されたデータベースがネガティブではなくポジティブであることの 1 つだと思います。

さて、あなたの編集に関しては、私が提案したものとほとんど違いはありません. あなたのテーブルは一意であると仮定しますitemid (これを 実際の列名dateとして使用しないでください)。

ただし、トランザクション テーブルに何かを追加するたびに、集計クエリを使用して各アイテムの最新の価格を算出する必要があることを意味します。私の提案は、価格の更新をより難しくしますが、価格の計算をより簡単にします。価格を更新するよりも定期的にアイテムの価格を計算するので、個人的には、私が提案したパフォーマンス ヒットを採用します。

于 2012-08-05T18:42:15.397 に答える