私は実際には別のテーブルを参照する一意のIDだけを必要とするデータベーステーブルをいくつか持っています。テーブルごとに新しい主キーフィールドを定義する必要がありますか？
Customer Holiday
******** *******
ID (PK) ---> CustomerID (PK)
Forename From
Surname To
....
このような休日などの表は、顧客に関する情報を保持するためにのみ存在します。したがって、休日のIDを保持する別のフィールドを指定する必要がありますか？すなわち
Holiday
*******
ID (PK)
CustomerID (FK)
...
この場合、CustomerIDをテーブルのプライマリキーとして設定するといいですか？
よろしく、 James。
これは実際にあなたがやっていることによって異なります。
各顧客が1つの休日しか持てない場合は、顧客のプライマリキーを作成することができます。
各顧客が複数の休日を持つことができる場合は、新しいID列を追加してプライマリにすることをお勧めします。これにより、顧客ごとに休日を選択し、固有のIDで個々のレコードを選択することができます。
さらに、各顧客が1つの休日しか持てない場合は、通常1対1の関係は不要なので、休日情報をテーブルに追加するだけです。
が決してである場合、顧客テーブルをHolidayのプライマリキーとして使用することはできません。つまり、ある顧客の2つの休日は、Customer IDを主キーとして使用して中断されます。
このデータベースに関連付けられたオブジェクト指向プログラムが存在する場合、各エンティティ（各行）には一意のキーが必要です。
2つ目の設計では、Holidayの各インスタンスを、OOアプリケーションが単純なオブジェクトリレーショナルマッピングを使用して一意に識別して処理できるようにします。
一般に、データベース内のすべてのエンティティには、一意の不変のシステム割り当て（「サロゲート」）キーがあることを確認するのが最善です。他の「ナチュラル」キーは、ビジネスロジックに合うようにユニークなインデックス、制約などを持つことができます。
前回の回答は正しいですが、各テーブルに2つの別個の主キーがあり、「休日」テーブルにCustomerIdの外部キーがあることを覚えておいてください。
次に、コード内の顧客への休暇の割り当てを管理して、1つの休暇を顧客に割り当てることができますが、これは問題の並行性をもたらします。同じ時間はおそらく顧客が2つの休日を有することになる。
顧客が唯一の休日を作成することができる場合でも、顧客テーブルの休日のフィールドを配置することもできますが、この設計は厄介で、本当にまだあなたの質問2で、だから、もう一度オプションを
に助言していません最適な方法は、あなたのオプションを与えるだけです。実際には、すべてのテーブルには、これらのテーブルのレコードを識別するユニークなプライマリキーが必要であることがわかりました。他のテーブルとのすべての関係を明示的に宣言する必要があります。
これは、特にスキーマを視覚的表現にリバースエンジニアリングするツールを使用する場合、他の人が関係をよりよく理解するのに役立ちます。
さらに、将来的にソリューションを拡張するための柔軟性が向上します。今は顧客ごとに1つの休日しかないかもしれませんが、顧客IDを主キーにすると変更するのがはるかに難しくなります。
休暇表で顧客の一意性を要求する場合は、その外部キーに一意のインデックスを作成します。実際、これは顧客IDを照会する際のパフォーマンスを向上させる可能性があります（ただし、この改善に気づくだけの十分なレコードがないと思いますが）。
この特定の例では、お客様は複数の休日を持つことができます。ただし、顧客がそのテーブルに1レコードしか持てない場合は、最初の例が最も適切でしょうか？ – James
James - 潜在的に。顧客あたり1レコードしかない場合は、顧客テーブルに追加することをお勧めします。 1対1の関係のための魅力的な理由がない限り。 –
+1良い点！私は各顧客が1レコードしか持っていないテーブルを持っています。私はそれをテーブルに分けた理由は、私がちょうど顧客テーブルに属していなかったというこの特定のテーブルに関するかなりの情報があったからです。 – James