ケータリング/メニュー管理のためのSQLデータベーススキーマ
バックグラウンド
私は、シェフを予約してカスタムメニューを調理できるプライベートシェフ予約サービスを構築しています。データの整合性を維持しながらドメインを正確に表すSQL dbスキーマを作成するのに問題があります。
必要条件
- お客様は、
BookingとChefを選択してMenuを作成し、それぞれに必要なMenuItemsを選択しますMenuCourse Chefは、顧客がMenuItemを作成するために選択できるBookingのセットを定義しますMenuはMenuCoursesのコレクションです。 （例：「テイスティングメニュー」という名前のMenuは6コースの食事で、各MenuCourseは$ 10-20の間です）。Chefは、MenuItemsを複数のMenusおよびMenuCoursesに関連付けることができる必要があります。- 顧客
Bookingには、選択されたChefと、提供されるMenu（およびMenuItems）が含まれている必要があります。Booking価格はMenuとMenuCourseの選択によって決まります（前菜はメインディッシュよりも安いです）
問題
現在のデータモデルでは、修正方法がわからない次の問題があります。
BookingをChefで作成することは可能ですが、BookingMenuItemを参照してMenuItemをChef"B"で参照することができます。 "（BookingMenuItemのすべてのBookingは、同じChefに属している必要があります）- a
Bookingは特定のMenuを参照します（価格設定に必要です。価格設定はMenuとMenuCourseに基づいています）。ただし、BookingMenuItemBookingは完全に異なるMenuまたはMenuCourseを参照できます
私が持っている整合性の問題を修正するために私のdbスキーマを再設計することは可能ですか？または、これらのチェックをアプリケーションレベルで実装する必要があるだけですか。ありがとう！
MenuItemsと関連するBookingMenuItemsに同じChefを設定することは、適切なデフォルト設定である可能性がありますが、データベースを通じて強制する必要はありません。実際には、シェフAがメニューを定義している可能性は十分にありますが、その場合、シェフAは利用できず、別のシェフBが料理を引き継ぐ必要があります。要するに、アプリケーションにこれを管理させ、例外を期待します。
2番目の問題については、アプリケーションまたはデータベースレベルでのトリガーによって技術的なソリューションを実装できます。常に可能または賢明であるとは限りません リレーショナルDBスキームであらゆる種類のサイクルを削除するため 。
ただし、最初に設計を再検討することをお勧めします。
メニューではデフォルトで提供されていないアイテムについて、顧客が「特別な願い」を抱いていることを期待します。そのため、追加のアイテム（およびそれらにも価格が必要）、または特別な要件を持つ既存のアイテムを予約できるようにする必要があります。準備、そしておそらく価格の変更（「トマトのないサラダが欲しいが、カッテージチーズの余分な部分が欲しい」-OK、それで結構です、私たちはあなたのためだけにこれを準備することができます3ドル49セント）。
予約時に提供されたすべてのメニュー項目が、シェフが調理したいときに利用できない可能性があり、彼らが代替品を見つける必要があることを期待します（多分いくつかの割引価格で）
予約には日付があり、特定のメニューのメニューの基本価格と計画されたメニュー項目は時間とともに変化する可能性がありますが、予約が行われたときの価格は通常、顧客に対して固定する必要があります。したがって、予約が行われたときに、現在の価格でメニューのコピーを作成し（多分
BookedMenuテーブルに）、この予約されたメニューに属するメニュー項目をコピーして、あらゆる種類の個別の変更を許可することをお勧めしますこのコピーに適用されます。
したがって、これらを個別にモデル化することをお勧めします。
利用可能なアイテム（メニュー、シェフ、および現在の価格設定とは無関係）
提供されたメニューとアイテム、および提供された価格
予約したメニュー/予約時の価格のアイテム、および追加の顧客の希望
食事が準備されて提供されるときのアイテム、おそらく供給不足などによる変化
このモデルを完成させたら、存在する冗長性/潜在的な不整合を再確認する必要があります。現在、2番目の問題は、モデルが時間の異なる状態、予約の「テンプレート」としてのメニュー、予約方法のメニュー、および調理方法と提供方法のメニューを明確に区別していないために存在するようです。