別のテーブルを参照する一意のIDのみを実際に必要とするデータベーステーブルがいくつかあります。
Customer Holiday
******** *******
ID (PK) ---> CustomerID (PK)
Forename From
Surname To
....
Holidayなどのこれらのテーブルは、実際には顧客に関する情報を保持するためにのみ存在します。したがって、休日のIDを保持するために別のフィールドを指定する必要がありますか？すなわち
Holiday
*******
ID (PK)
CustomerID (FK)
...
または、この場合、CustomerIDをテーブルの主キーとして設定するだけで大丈夫ですか？
よろしく、ジェームズ。
これは本当にあなたがしていることに依存します。
各顧客が休日を1つしか持てない場合は、はい、customeridを主キーにすることができます。
各顧客が複数の休日を持つことができる場合は、いいえ、新しいID列を追加して、それをプライマリにします。これにより、各顧客の休日を選択したり、一意のIDで個々のレコードを選択したりできます。
さらに、各顧客が1つの休日しか持てない場合は、1対1の関係は通常不要であるため、休日情報をテーブルに追加するだけです。
私があなたの質問を正しく理解している場合、テーブルにその顧客の他の休日がない場合にのみ、休日の主キーとして顧客テーブルを使用できます。つまり、1人の顧客の2つの休日は、顧客IDを主キーとして使用して休憩します。
実際には、すべてのテーブルに、それらのテーブル内のレコードを識別する一意の主キーが必要であることがわかりました。他のテーブルとの関係はすべて明示的に宣言する必要があります。
これは、他の人が関係をよりよく理解するのに役立ちます。特に、ツールを使用してスキーマを視覚的表現にリバース エンジニアリングする場合に役立ちます。
さらに、将来的にソリューションを拡張する柔軟性が高まります。現在、顧客ごとに休日は 1 つしかない場合がありますが、顧客 ID を主キーにすると、これを変更するのがはるかに難しくなります。
休日テーブルで顧客の一意性を義務付けたい場合は、その外部キーに一意のインデックスを作成します。実際、これにより、顧客 ID をクエリする際のパフォーマンスが向上する可能性があります (ただし、この改善に気付くほどのレコードは表示されないと思います)。
このデータベースに関連付けられたオブジェクト指向プログラムが存在する場合、各エンティティ (各行) には一意のキーが必要です。
2 番目の設計では、単純なオブジェクト リレーショナル マッピングを使用して、OO アプリケーションが Holiday の各インスタンスを一意に識別して処理できるようにします。
一般に、データベース内のすべてのエンティティに、一意で不変のシステム割り当て (「代理」) キーがあることを確認することをお勧めします。他の「自然な」キーは、ビジネス ロジックに適合するように一意のインデックス、制約などを持つことができます。
前の回答は正しいですが、覚えておいてください。各テーブルに 2 つの別々の主キーを設定でき、「休日」テーブルには CustomerId への外部キーを設定できます。
次に、コードで顧客への休日の割り当てを管理して、顧客に割り当てられる休日が 1 つだけであることを確認できますが、これは問題の並行性をもたらします。2 人が同時に顧客に休日を追加することになります。ほとんどの場合、顧客は 2 つの休暇をとることになります。
休日でしか顧客を作成できない場合は、顧客テーブルに休日フィールドを配置することもできますが、この設計は面倒であり、あまりお勧めできません。
繰り返しになりますが、質問2のオプションは、オプションを提供するだけで、最善の方法です。