開発者が犯した最も一般的なデータベース設計の間違いを読んでいました Q & A 。最初の答えは、排他的アークについてのフレーズでした。
排他的アークは、テーブルが2つ以上の外部キーで作成され、1つとそのうちの1つだけがnull以外になることができます。大ミス。一つには、データの整合性を維持することがはるかに難しくなります。結局のところ、参照整合性があっても、これらの外部キーの2つ以上が設定されるのを妨げるものは何もありません（複雑なチェック制約にもかかわらず）。
私は本当にしません「排他アークが悪である理由がわからない。おそらく私はその基本を理解していなかった」。排他的アークについての良い説明はありますか？
回答
私がずっと前に理解した限りでは、排他的アークテーブルには、他のテーブルへの外部キーであるいくつかの列が含まれていますが、一度に設定できるのはそのうちの1つだけです（現実の世界から続くドメインに対する論理的な制約のため）。このルールはデータベースに適用できないため、これらの外部キーの複数に値がある場合に破損したレコードが作成される可能性があります。
例を示します。企業が追跡しているアプリケーションについて考えてみます。トラックは、商品の配送に使用します。トラックは、従業員と一緒、駐車場、またはメンテナンスショップの3か所のいずれかに同時に配置できます。これはモデル化できます。 employeeId、parkingGarageId、maintenanceShopIdを含むTruck-tableを作成し、Employee、ParkingGarage、MaintenanceShop-tablesを参照します。データベースのレベルで、これらのフィールドの1つだけに入力するというルールを適用する方法はありません。不正なコードまたはデータベースに直接アクセスできる人が、2つまたは3つのフィールドが入力されたレコードを挿入する可能性があります。これは、データベースのデータ破損に相当します。
コメント
回答
排他的なアークについては何も悪いことはありません。チェック制約を使用して、対応するビジネスルールを適用するだけです。ほとんどの主要なデータベース管理システムは、チェック制約をサポートしています（Oracle、SQL Server、PostgreSQL）。 「データモデリングツールを使用している場合は、ツールがチェック制約を実装するためのコードを自動的に生成する可能性が高くなります。
回答
排他的アークは、概念設計または論理設計で非常に役立ちます。そのように実装する必要があるという意味ではありません。前の例では、設計者は3つのテーブルを使用して設計を実装することを決定できます。1つは駐車用です。場所、1つは従業員用、もう1つはメンテナンスショップ用です。
alter table mytable add constraint myconstraint check ((col1 is not null and col2 is null and col3 is null) or (col1 is null and col2 is not null and col3 is null) or (col1 is null and col2 is null and col3 is not null))です。 '排他的アークは好きではありませんが、チェック制約を使用して適用できます。もちろん、FK制約も存在する必要があります。