4

そのため、カテゴリ、製品、および製品のバリエーションの基本的な表があります

カテゴリ
id | name | active | parent_id

製品
id | name | price | active

c_p_link
category_id | product_id

バリアント
id | product_id | price | price_override | active | stock

これはうまくいきます。

しかし、2つのクエリがあります。

1つ目は、注文の構成方法です。

注文表があります
id | customer_id | ordered | status

また、order_productsテーブルもあります
id | order_id ..?

これは私が興味を持っているものです。顧客が30個の製品を注文したとします。私たちは

  • 30行を追加し、各行の個々のアイテムの価格を追加します。
  • 1つの行を追加し、合計を行に追加します
  • 行を1つ追加し、個々の価格を行に追加します

次の部分は、後でカートにバウチャーサポートを追加する予定です。たとえば、10％オフ、2つ購入、1つ無料など。これの全体的なデザインは、今のところあまり気になりません（少なくとも数か月はオフです）。しかし、それがorder_productsテーブルのどのバージョンを選択する必要があるかに影響するかどうか疑問に思っていますか？

4

2 に答える 2

2

免責事項： 「ショッピングカート」または「注文」を扱うデータベースモデルを作成したことはありません。

購入時の価格は、店舗からの紙の領収書のように、購入データにエンコードする必要があると思います。これをレシートの各項目別の「行」を表すものと呼びましょう。total_priceと混同しないでくださいtotal_purchase_price。

つまり、請求額は固定されています。製品の価格が後で変更されるかどうかは関係ありません。価格の変更は、支払われる金額に反映されるべきではありません。

したがって、次のフィールドがあります：product、、、。たとえば、 （ ）の計算列は、必要に応じて簡単に追加できます。unit_pricequantitytotal_pricebase_total_priceunit_price * quantity

さて、は、 sayフィールドtotal_priceに基づいて計算された値である可能性があります。しかし、最終的には、それが存在し、購入時に修正される必要があると私は考えています。（これは、計算列の場合、すべての入力も購入時に固定されることを意味します。）base_total_price * precent_discounttotal_price

補遺：前述のように、私はこれまでこのようなモデルを設計したことはありませんが、店舗で観察したことの1つは、割引が負のコストの項目別アイテムとして適用されていることです。つまり、アイテムは「定価」で購入され、レジスターは、プロモーションが行われている場合のコストを相殺するためのエントリを追加します。そのようなアプローチのメリット/理由はわかりません。

于 2012-11-12T04:32:42.167 に答える
0

order_productsテーブルに商品の数量を追加するだけです:)

私は3番目のソリューションを好みます。これは、データベースのパフォーマンスに最適だと思います。

于 2012-11-12T04:11:00.733 に答える