2

ホテルの部屋を管理するアプリを書いていますが、割引価格を管理するために DB を設計する必要があります。Room テーブルと Price テーブルは既に作成済みで、管理者が条件に応じて適用できる割引を保存できるテーブルをいくつか作成する必要があります。管理者は新しい割引も作成できます。例えば：

  • 9 月に予約を開始すると、ユーザーは 10% 割引を受けることができます。
  • 2 週間以内に部屋を予約する場合、ユーザーは 10% の割引を受けることができます

したがって、ここに私の簡略化された表があります（質問に関係のないフィールドと関係は省略しました）：

部屋：

id | name
---|----------------
 1 | Trafalgar Square
 2 | Piccadilly

価格:

id | room_id  | base | promotion 
---|----------|------|-----------
 1 |    1     | 10   | 8
 2 |    2     | 25   | 20

上記のような条件を保存するにはどうすればよいですか? 私はRailsを使用していますが、最初に考えた解決策は、割引が適用されることとそれを適用する条件を保存できるテーブルを作成することでした。フィールド条件を SQL スニペットと考えました。のようなものなReservation.start_date > [date]ので、Rails でそれらを連結してさらに割引を適用できます。しかし、これは非常に醜いソリューションであり、DBRMS と結合しているため、この選択は避けたいと思います。

この問題を解決するために何かを実装する方法を知っていますか? 問題を明確に説明できたことを願っています。

4

4 に答える 4

2

素晴らしい質問です。

私はホテルの予約システムに取り組んだことはありませんが、割引戦略のあるeコマースプロジェクトに取り組んだことがあります。悪いニュースは、これが非常に急速に複雑になる可能性があることです。

たとえば、特定の予約に適用される複数の割引があり、それらが累積的であるか、相互に排他的であるかを検討する必要がある場合があります（「すべての予約の10％」割引があり、予約が「新規」の対象となる場合-水25％オファー」、10％、25％、35％のどれを提供しますか？）税金を処理する必要がある場合は、さらに奇妙になります。予約全体に複数の商品があり、税率が異なる場合、割引を適用した後、どのように税金を計算しますか？

ユーザーが新しい（タイプの）割引を指定できるシステムを構築することに夢中になっている場合、それに伴うすべてのルールを使用すると、プロジェクトはかなり大きく、非常に複雑になり、割引エンジンに夢中になります。

それがあなたがいる世界なら、@ChrisLivelyの答えを聞いてください。ルールエンジンに投資し、割引がどのように機能するか、「and」、「or」、「xor」などが何を意味するかを説明するために、次のかなりの時間を費やす準備をします。

ただし、理想的には、実際の現在の要件を調整するためにもう少し時間を費やす可能性があります。5つの実際の例を解くだけでよい場合、オプションは、汎用の割引エンジンを構築するよりもはるかに制限されます。戦略パターンと複合パターンを見てください。それが「一般的な目的」でない場合は、データベースに保存されるのではなく、有効期限がハードコーディングされた「2012年夏」の割引戦略を作成することに恥はありません。

于 2012-05-21T21:42:42.053 に答える
2

これを処理するために何らかの種類のルール エンジンを使用して調査することを強くお勧めします。

問題は、多くの業界と同様に、ホテルが非常に流動的な価格設定方法を使用していることです。気まぐれに見えるものもあれば、思考にほとんど似ていないものもあり、すべて構造化されたアプローチを作成するのが困難です。

たとえば、1 泊が予約されていて、クライアントが午後 11 時以降に予約を行った場合、部屋は 10% 割引されます。金曜または土曜の夜でない限り、またはホテルの定員が 80% 以上の場合を除きます。

標準割引が 15% である 1 月の場合、このルールは中断される可能性があります。

大会が町で予定されている場合、その規則は中断される可能性があります. その時点で、客室料金は 30% 引き上げられます。

別のアプローチとして、システムが客室料金を自動的に計算するのをやめて、予約時にホテルのスタッフに料金を設定してもらうという方法があります。この場合、現在の「スペシャル」に関するガイドラインを表示するだけです。

確かに、それは自動的に行うほど魅力的ではありませんが、問題のホテルが既にこれを行っている COTS を購入するつもりがない場合、適切に開発するために必要なコストを支払うことはないでしょう。

于 2012-05-21T21:16:23.213 に答える
2

多くの場合、予約スタッフはさまざまな割引を適用する権限を与えられています。言い換えれば、割引のルールは遡及的にスポットチェックされるだけです.

システムに特定の割引の資格を自動的にチェックさせると、すぐに次のようになります。

  • 複雑すぎて理解できない (新しい割引とそのルールを追加しようとしている管理者にとって)
  • 複雑すぎてシステムを実装できない (増え続ける状況のリストを予測する必要がある)
  • もろすぎる（完全に合理的で適切な「例外」が常に存在します。）
  • 一部割引不可。たとえば、誰かが結婚式に出席していて、結婚式のグループの割引を受ける資格があることをどのように「証明」できますか。

多くの場合、割引はマーケティングの問題です。このような場合、ルールを介して割引の適格性を厳密に制御するのではなく、顧客が要求した割引 (「ジョーンズの結婚式の割引」) を知りたいと考えています。

割引システムのより有用な側面は、チェックイン システムが、顧客が割引資格の証明を提示する必要があるかどうかを確認し、必要な場合はチェックイン係にプロンプ​​トを表示することです。たとえば、会社の契約割引率が予約に使用されている場合は、従業員 ID を尋ねます。

ホテルの予約と部屋の管理システムは非常に複雑です。ホテルが COTS (市販の市販) ソフトウェアを使用しない理由を理解する必要があります。

于 2012-05-21T21:58:56.477 に答える
1

これが私のコメントの拡張版です。データベースにSQL/実行可能コードを入れることは一般的に悪い考えであることに同意します。この場合、それを避けることができると思います。

私はこのようにします：

昇進
-------------------------------------------------- ----------
ID (pk) | 短い名前 (一意) | パラメータ？| | serialized_pa​​rams?
1 | september_promo | ... |
2 | 長期滞在 | ... |
-------------------------------------------------- ----------

room_promotion
-------------------------------------------------- --
room_id (fk) | プロモーション_id (fk) | serialized_pa​​rams
1 | 1 | {割引=10; 開始日=x; end_date=y }
2 | 2 | { 長さ=14 }
-------------------------------------------------- --

このアプローチにより、実行したいプロモーションの種類に最大限の柔軟性が得られます。各プロモーションには、ビジネス ロジックに応じて多数のパラメーターがあるため、部屋ごとのケースでは、シリアル化されたパラメーターの列を用意して、このテーブルに未使用の列を多数持たないようにすることをお勧めします。これはいくつかのリレーショナル ルールに違反することに留意してください。

同様に、各プロモーション行に対してパラメーターまたはシリアル化されたパラメーターを使用することもできます (たとえば、'long_stay' プロモーションのすべての使用が 14 日間であることがわかっている場合)。

複数のプロモーションを部屋に適用できるように「room_promotion」テーブルを配置したことに注意してください。常に一度にしか適用できない(room_id, promotion_id)ことが確実な場合は、主キーを作成できます。

これで、「プロモーション ルール」を適用できるメカニズムができました。ただし、ビジネス ロジックは引き続きコードに属します。そのため、短縮名を検索してキャメルケースにし、Ruby の動的検索メカニズムを使用して割引を適用します。Ruby は使用しませんが、PHP のスケッチ形式では次のようになります。

    オブジェクト $Bill の取得 (割引が適用される前)
    $ディスカウント = ディスカウントファクトリー::getInstance(
        'september_promo',
        unserialize($serialized)
    );
    $Bill->applyDiscount($Discount);
    変更された請求書の表示

内部的には、クラスであるseptember_promoに変換されるSeptemberPromoと思います (申し訳ありませんが、PHP が再び):

クラス SeptemberPromo は Promotion を拡張します
{
    // ここに抽象メソッドの具体的な実装を追加します
    public function executeDiscount($Bill) { ... }
}

applyDiscount()次に、プロモーションは、部屋ごとの値、プロモーションごとの値、および請求書の詳細を考慮して、適用する割引を決定するために使用される抽象メソッドを持つことができます。

ディスカウント ビジネス ロジックをかなり一般的なものにしておく限り、ホテル マネージャーは、新しいプロモーションごとに新しい Ruby コードを必要とするのではなく、シリアル化されたパラメーターを使用してそれをカスタマイズできます (新しいプロモーションタイプが必要な場合を除く)。そのことを念頭に置いて、SeptemberPromoはおそらく具体的すぎるでしょう。

もちろん、ホテルの支配人が新しい行を格納できるように UI を構築する必要がありますpromotionがroom_promotion、それは非常に簡単なはずです。

于 2012-05-21T20:59:14.550 に答える