データベースの排他的アークとは何ですか？なぜそれが悪いのですか？

私は、stackoverflowに関する開発者のQ＆Aによって発生した最も一般的なデータベース設計の間違いを読んでいました。最初の答えは、排他的な弧についての句がありました：

排他的アークは、テーブルが2つ以上の外部キーで作成され、そのうちの1つだけがnull以外になる可能性がある一般的な間違いです。大ミス。1つには、データの整合性を維持することがはるかに困難になります。結局のところ、参照整合性があっても、これらの外部キーの2つ以上の設定を妨げるものはありません（複雑なチェック制約にもかかわらず）。

なぜ独占アークが邪悪なのかよくわかりません。基本的には理解できなかったのでしょう。独占アークについての良い説明はありますか？

ずっと前に私が理解した限りでは、排他的な弧には、テーブルに他のテーブルへの外部キーである列がいくつか含まれていますが、一度に設定できるのはこれらの1つだけです（ドメインに対する何らかの論理制約のため）。現実の世界から続く）。このルールはデータベースに適用できないため、これらの外部キーの1つ以上に値がある場合に破損したレコードが作成される可能性があります。

例を挙げましょう。会社が商品の配送に使用するトラックを追跡するアプリケーションを考えてみましょう。トラックは、同時に3つの場所のうちの1つにしか存在できません。従業員と一緒にいることも、駐車場にいることも、メンテナンスショップにいることもできます。これは、employeeId、parkingGarageId、maintenanceShopIdを持つトラックテーブルを作成し、Employee、ParkingGarage、MaintenanceShopテーブルを参照することでモデル化できます。これらのフィールドの1つだけがデータベースのレベルで入力されるというルールを適用する方法はありません。不正なコードまたはデータベースに直接アクセスできる誰かが、2つまたは3つのフィールドが入力されたレコードを挿入する可能性があり、これはデータベースのデータ破損を意味します。

排他的なアークについては何も悪いことはありません。チェック制約を使用して、対応するビジネスルールを適用するだけです。ほとんどの主要なデータベース管理システムはチェック制約をサポートしています（Oracle、SQL Server、PostgreSQL）。データモデリングツールを使用している場合は、ツールがチェック制約を実装するコードを自動的に生成する可能性が高くなります。

排他的弧は、概念設計または論理設計で非常に役立ちます。そのように実装する必要があるという意味ではありません。以前の例では、設計者は3つのテーブルを使用して設計を実装することを決定します。1つは駐車場用、もう1つは従業員用、もう1つは整備工場用です。