必要ないように見えるので、これに主キーを含める必要があるかどうかわからないので、誰かがこれを理解するのを手伝ってくれますか?
次のように2つのテーブル構造があります。
表 1: プログラム
program_id
cycle_unit表 2: program_has_days
日
週
program_id
プログラムは完了するまでに何日もかかることがあるため、プログラムには表 2 に示すスケジュールがあります。スケジュールには、プログラムを完了することができる曜日 (たとえば、第 1 週の第 1 日、次に第 2 週の第 3 日) がリストされています。 . ここでは、1 対多の関係があります。テーブル番号 2 に主キー (id) を配置する必要があるかどうか疑問に思っています。
スケジュールを直接参照しないため、主キーは必要ないと思います。スケジュールを取得するには、常に program_id を参照します。この場合、program_id は一意ではないため、主キーにすることはできません。
同じ日/週に多くのプログラムを実行しない場合は、テーブル 2 に PK は必要ありません。
ただし、同じ日/週に多くのプログラムを実行する場合は、テーブル 2 に PK を追加し、それらの間に 3 つ目の結合テーブルを作成することをお勧めします。こうすれば、同じ日/週の組み合わせに対して表 2 に複数の行が表示されることはありません (つまり、その特定の日/週に存在するすべてのプログラムについて行を保持しても意味がありません)。これにより、適切な日/週が既に存在するかどうかを確認する際の複雑さが増します。
このアプローチは、特定の日/週に実行されるプログラムを効率的に検索することに関心がある場合に特に関連があります (ただし、そうではないと言っていましたが...)。
別のケースとして、プログラムを複数のスケジュールで実行する必要がある場合があります (たとえば、プログラムは数週間実行されます (概要を説明したように、毎日異なるレコードを使用))。ただし、プログラムは 6 で再実行されます。異なるスケジュールの日/週などで数か月。または、おそらく 2 つの異なるが同時のスケジュールでしょうか?) . これには、個別のスケジュールを追跡する結合テーブルを含むテーブル 2 の PK、または特定の日/週/番組の組み合わせがレコードが属するスケジュールのインスタンスを区別するためのテーブル 2 の別のキーが必要です。
はい、良い習慣です。いいえ、必要ありません。すべてのテーブルに主キーを設定することをお勧めします。これは後で、テーブルのデータを実際に参照する必要があると判断した場合に役立ちます。たとえ、そのフィールドの他の一意のセットを指定することなく、数行を削除するだけであってもです。