外部キーの整合性を壊すときにほとんど同じであるエンティティに同じテーブルを使用しますか？
私は、ユーザーがサインアップできるイベントfxをサポートするデータベースを備えたWebサイトを設計しています。コンサート。ユーザーは、内部登録システムを使用するか、外部Webサイト（リダイレクト先）を使用してサインアップできます。
したがって、イベントは内部または外部になります。どちらのタイプのイベントにも、日付、タイトル、場所などの同じタイプのメタデータがあります。イベントが内部の場合、一部のcanテーブルは外部キーfxを使用してイベントIDを参照します。多対多のテーブルusers_eventsには、内部イベントに関連する請求データを処理するテーブルもいくつかあります。
私の現在の設定は、前に述べた列、日付、タイトル、場所などを含む単一のeventテーブルです。また、external_signup_url列もあります。これは、イベントが内部の場合はNULLであり、イベントが外部の場合のURL。この設計の問題は、外部キーによってイベントIDを参照するテーブルが外部イベントを参照する可能性があることです。これは、アプリケーションレベルでは意味がありません。
したがって、私の質問は、2つのタイプのイベントが（属性に関して）非常に似ているにもかかわらず、わずかな違いがあり、潜在的な無意味な外部キー参照は、実際には別々のテーブルfxを保証するということです。 external_eventおよびinternal_event？
通常、データベースにアクセスする人がアプリケーションの動作を把握できるようにデータベースを設計します。彼らがそのような外部キーを見たならば、彼らはそれの意味に気づいていないかもしれません。
これには2つの方法でアプローチできます。まず、前述のように行うことができます。 2つの別々のテーブルを作成し、そこで処理します。
次に、私がお勧めする方法では、2つの間のすべての共通フィールドを処理するテーブルを作成し、次に他の2つのテーブル（1つは内部固有のデータ用、もう1つは外部固有のデータ用）を作成します。これらの各テーブルには、共通テーブルへの主外部キーがあります。つまりGUIDまたはID。
2番目の方法の欠点は、アプリケーションが2つの異なるテーブルを認識する必要があることです。アプリケーションの実装に使用している方法（.NET、PHP、Pythonなど）によっては、1つの方法の方が簡単な場合があります。その他。
私は個人的に.NETとC＃またはVBをプロジェクトに応じて使用します。この状況では、抽象クラス（ "Event"）を作成し、次に2つのクラスを作成してそれを継承するため、3つのテーブルの設計を使用します。共通のプロパティ（ "ExternalEvent"、 "InternalEvent"）。 Eventクラスは共有プロパティの相互作用を処理し、InternalEventとExternalEventはそれらに固有のロジックを処理します。
このアプローチの利点は、その多態性です。将来（前例のない理由で）2つに共通のフィールドを追加する場合は、1つの場所で追加/変更するだけで済みます。