私は、ユーザーが自分の「コンボ」を構築し、選択に応じて割引を得ることができる、このWebサイトのビジネスロジックを「想像」しようとしています(1、3 、6および12か月プラン)。
データベースフィールドのJSONエンコードデータに頼らずに、データベースを正規化し、適切な関係を維持しながら、解決策を考え出すのに苦労しています。システムは、計画/活動に依存する多くのビジネスタイプに適合するのに十分な汎用性を保つ必要があります。 テーブルを構造化する方法を知る必要があります。
シナリオ:たとえば、ジムの場合、ボディービルディング、ヨガ、ボクシング、ボディポンプを使用します。人がボディービルとボクシングを選択した場合、彼らは割引を受けます。彼らがヨガを追加する場合、ボクシングとボディービルは割引を維持しますが、価格に割引なしでヨガを追加します。その人が12か月前払いすることを決めた場合、彼らはより大きな割引を受けます。
ボディービル+ボディポンプ
Bodybuilding..$70 | 28% discount
Body Pump.....$70 |
Total........$100
1 month - $100 / month
3 months - $ 91 / month
6 months - $ 75 / month
ボディービル+ボディポンプ+ヨガ
Bodybuilding..$70 | 28% discount
Body pump.....$70 |
Yoga..........$90 | No discount
Total........$190
1 month - $190 / month
3 months - $171 / month
6 months - $158 / month
私はPHPとMYSQLを使用しますが、RDBMSの部分のみでそれほど重要ではありません。
明確化のために編集:私が本当に探しているのは、単一の価格/オファーの下で製品(またはこの場合はサービス)をパッケージ化するためのデータベーススキーマです。各製品は、スタンドアロン製品としてシステムに存在する必要もあります。
製品がパッケージの一部として販売された場合でも、製品ごとの売上(および利益)をレポートする機能が必要です。
パッケージのパフォーマンスをレポートする機能が必要です。
最低限必要なもの:
残念ながら、正確なERDをお伝えすることはできません。プロモーションの条件は企業によって大きく異なるため、必要に応じて複雑にするか単純にするかはお客様次第です。たとえば、SKUごとのプロモ、カテゴリごと、サブカテゴリごと、ブランドごとのプロモが必要ですか、特定のSKUを除外する必要がありますか?、ブランド?カテゴリー?発送場所は?
最後に、これを維持および調整しやすくするようにしてください。すべての拠点をカバーしたと思ったときだけ、ビジネスチームは新しいクレイジーなプロモーションを思い付くでしょう地球上の顧客は理解できません使い方
編集: *これで、ここであなたの質問をよりよく理解できるようになりました:*
パッケージヘッダーテーブルとラインアイテムテーブル、パッケージ名と説明はヘッダーに保存され、ラインはアイテム(そのパッケージの一部として販売された場合のアイテムの価格を含む)を保持します。
注文するパッケージを追加する方法が必要です。それが完了したら、パッケージ内の各アイテムを通常のラインアイテムとして追加しますが、アイテムがパッケージとPackageIDの一部であることを指定する追加のフィールドがあります。
次に、注文をどのようにコード化するかを決定するのはあなたです。印刷、パッケージの合計を印刷するだけで、顧客はラインアイテムの価格を知らないか、通常どおりに印刷しますが、パッケージの説明を追加します。