1：1外部キー制約

Question

transact sqlで外部キー制約を1：1の関係にする方法を指定しますか？ UNIQUEという列は十分に宣言されていますか？以下は私の既存のコードです！

CREATE TABLE [dbo].MyTable(
    [MyTablekey] INT IDENTITY(1,1) NOT FOR REPLICATION NOT NULL, 
    [OtherTableKey] INT NOT NULL UNIQUE 
     CONSTRAINT [FK_MyTable_OtherTable] FOREIGN KEY REFERENCES [dbo].[OtherTable]([OtherTableKey]), 
    ... 
    CONSTRAINT [PK_MyTable] PRIMARY KEY CLUSTERED 
    (
     [MyTableKey] ASC 
    ) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] 
) ON [PRIMARY] 
GO 

Answer 1

UNIQUEおよびNOT NULL制約を持つ外部キー列が、別の表のUNIQUE、NOT NULL列を参照すると、おそらく必要な1：（0 | 1）の関係が作成されます。

真の1：1の関係があった場合、最初のテーブルのすべてのレコードは2番目のテーブルに対応するレコードを持ち、逆も同様です。その場合、おそらく1つのテーブルを作成するだけです（奇妙なストレージの最適化が必要な場合を除きます）。

Answer 2

この列を主キーと外部キーの両方として宣言できます。これは、ヌル可能な列をメインテーブルに置かないようにするための "拡張"テーブルのための良い戦略です。

Answer 3

上記のコードに基づいて、ユニークな制約は、テーブルにあるすべてのプライマリキーについて、一意の制約付きの列も一意であることを考えると十分です。また、これは、[OtherTable]で[OtherTableKey]列がその表の主キーであることを前提としています。

Answer 4

真の1：1の関係があった場合、最初のテーブルのすべてのレコードは2番目のテーブルに対応するレコードを持ち、逆も同様です。その場合、おそらく1つのテーブルを作成するだけです（奇妙なストレージの最適化が必要な場合を除きます）。

これは間違いです。私に例を挙げてみましょう。たとえば、システムのロジックがそうであるため、テーブルSALES_OFFICEと1対1の関係を持つテーブルCLIENTがあります。本当にSALES_OFFICEのデータをCLIENTテーブルに組み込みますか？そして、別のテーブルがSALES_OFFICEでそれらの自己を関連付ける必要がある場合は？そして、データベースの正規化のベストプラクティスとパターンはどうですか？

UNIQUEおよびNOT NULL制約を持つ外部キー列は、別の表のUNIQUE、NOT NULL列を参照するため、おそらく必要な1：（0 | 1）の関係が作成されます。

第2のテーブルのデータが本当に最初のテーブルに属していて、他のテーブルで使用されることのない種類の情報でない限り、答えの最初の部分は正しい答えです。

Answer 5

@bosnic：例えば、あなたのシステムのロジックはそう言って、ため、表SALES_OFFICEと1の関係：

あなたは1を持っているテーブルのクライアントを持っています。

あなたのアプリケーションロジックが何を言っているのか、そしてあなたのデータモデルが言っていることは2種類あります。ビジネスロジックコードとの関係を強制することには何も問題はありませんが、データモデルにはその場所がありません。

本当にSALES_OFFICEのデータをCLIENTテーブルに組み込みますか？

すべてのクライアントは、ユニークなSALES_OFFICEを持っており、すべてのSALES_OFFICEは単数、一意のクライアントを持っている場合 - [はい、彼らは同じテーブルにする必要があります。私たちはより良い名前が必要です。;）

そして、別のテーブルが自己とSALES_OFFICEを関連付ける必要がある場合は、

理由はありません。 CLIENTには一意のSALES_OFFICEがあるため、他のテーブルをCLIENTに関連付けます。

データベース正規化のベストプラクティスとパターンはどうですか？

このは、である。

は、公正、SALES_OFFICEであるために、クライアントは明らかに1ではない：1の関係 - それは1です：N。うまくいけば、あなたのSALES_OFFICEは複数のクライアントにサービスを提供するために存在し、クライアントがなくても（しばらくの間は）存在し続けるでしょう。

もっと現実的な例は、SALES_OFFICEとZIP_CODEです。 SALES_OFFICEは正確に1 ZIP_CODE、及び2 SALES_OFFICEsを有していなければならない - それらは同等ZIP_CODEであっても - ZIP_CODEのインスタンスを共有していない（したがって、1のZIP_CODEを変更すると、他に影響を与えません）。 ZIP_CODEがSALES_OFFICEの列として属することに同意しないでしょうか？