3

笑わないでください。私は Lotus Notes (非リレーショナル データベース!) の開発者で、SQL を操作しようとしています。基本的な概念はしっかりと把握していますが、「高度な」と思われるものに行き詰まっています。

ユーザーが一連の製品をバスケットに追加して、オンライン チェックアウトに到達したとします。カートにプロモーションを適用する必要があります。

これらのプロモーションは、バスケット内のアイテムを見て、事前に定義された「バンドル」に一致する組み合わせに対して「ポイント」を追加します。プロモーションでは、特定の国のユーザー (登録時に取得した情報) やその他の個人情報をターゲットにする必要もあります。

プロモーションは、サイト管理チームによって入力および維持され、可能な限り柔軟である必要があります. そのため、「タイプ Y の X 製品を購入して 50% の追加ポイントを獲得」または「3 台以上の XE-123 で 500 ポイントを追加」などの報酬を与えることができます。

今、私は一般的な方向性を探しています。バスケット内のアイテムを実行中のプロモーションに一致させる基準をどのように保存すればよいですか? バスケット ループを作成する C# コードは、すべてのプロモーションをループして、どれが適合するかを確認しますか?

現在、テーブル スキーマさえありません。それがどのように機能するかについての知識だけで、どこから始めればよいかほとんどわかりません。

ジェイク

4

2 に答える 2

1

私の提案は、この種のビジネス ロジックに SQL を使用しないことです。

データベースは、タイプ Y かタイプ X かなどの製品に関する情報を保持するのに適した場所です。これにより、データベースの設計が非常に単純になります。

あなたがC＃について言及したことは、より良い方向のようです。この戦略の利点を説明するのに役立つ、3 層アーキテクチャに関する検索可能な情報がたくさんあります。

于 2010-08-26T12:50:20.650 に答える
0

「可能な限り柔軟に」は危険信号です (IMHO)。私はそれを次のように突き止めようとします：

  • 「固定小数点および/またはパーセンテージ (合計バスケット/バンドル ポイントの) ボーナス (ヘルパー テーブルの 3 つの列)
  • 事前定義された「バンドル」に一致する組み合わせがバスケットに含まれている場合、「バンドル」はヘルパー テーブルに含まれており、複数の行があり、bundleID とバンドル内の各アイテムの行があり、少なくとも ItemID と Quantity が含まれています。 .

そして、他の種類の報酬はありえません。これにより、プロジェクト/要件を管理しやすくすることができます。

次に、バスケット内のバンドルの存在をチェックし、関連するプロモーションを適用する SP を用意します (最初のヘルパー テーブルに格納されているとおり)。

また、1 つまたは複数のプロモーションが可能かどうかの要件も確認してください。

于 2010-08-26T08:46:23.300 に答える