うまくいけば、私の説明はタイトルよりも少し良くなりますが、基本的には新しいアプリケーションスキーマの一部に問題があり、テーブル構造で最も管理しやすくエレガントなソリューションに固執しています。
関連するフィールドのみが表示されているベアボーンテーブル構造は次のようになります。
航空会社（id、name、...）
ホテル（id、name、...）
サプライヤー（id、name、...）
event（id、name、...）
eventComponent（id、name）{eg Food Catering 、Room Hire、Audio / Visual ...}
eventFlight（id、eventid、airlineid、...）
eventHotel（id、eventid、hotelid、...）
eventSupplier（id、eventid、supplierid、hotelid、eventcomponentid、.. .. ）。
したがって、航空会社、ホテル、サプライヤーはすべて参照テーブルであり、イベントはこれらの参照テーブル間の1対多の関係で作成されます。たとえば、イベントには2つのフライトエントリ、3つのその他のコンポーネントエントリ、および2つのホテルエントリが含まれる場合があります。ただし、問題は、EventSupplierテーブルでは、サプライヤーがサプライヤーまたは既存のホテルのいずれかである可能性があることです。したがって、ユーザーがフロントエンドで新しいイベントを作成した後、後でこのデータを返すのが悪夢にならないように、これを保存する必要があります。
私はポリモーフィックな関係と排他的なアークについて多くのことを読んでいます、そして私のシナリオは間違いなく線に沿っているか、排他的なアークの関係だと思います。
私が考えていた：
CREATE TABLE eventSupplier（
id SERIAL PRIMARY KEY、
eventid INT NOT NULL、
hotelid INT、
supplierid INT、
CONSTRAINT UNIQUE（eventid、hotelid、supplierid）、-UNIQUEはNULLを許可し
ますCONSTRAINT CHECK（hotelid ISNOTNULLまたはsupplieridISNOT NULL）、
FOREIGN KEY（hotelid）REFERENCES hotel（id）、
FOREIGN KEY（supplierid）REFERENCESsupplier（id）
）;
次に、このデータを取得するには、両方のテーブルへの外部結合を使用して、どちらがリンクされているかを判断します。
イベントIDとしてe.idを選択し、 eventSupplier
からの サプライヤーとしてcoalesce（h.name、s.name）を選択
し ます 。 .idがnullでない、またはs.idがnullではない
私の他のオプションは、eventSupplierテーブルに単一の外部キーと「タイプ」の別のフィールドを含めることでした。これはデータを取得するのが難しいソリューションのようですが、これを拡張せずにトラックを拡張したい場合は非常に柔軟に見えます。スキーマを変更する。または、hotelidをSupplierテーブルに直接保存し、一部のサプライヤーを「ホテル」として宣言することもできますが、不要な冗長データがあります。
これについての考えは大歓迎です！
乾杯フィル
