Использовать составной ключ в качестве первичного ключа или иметь 2 внешних ключа и другое отдельное поле в качестве первичного ключа?

Question

У меня есть следующие таблицы:

| студент |

• studentID (P)
• Имя
• ...

| Вакансии |

• JobID (P)
• JOB_NAME
• ...

| Применение |

• JobID
• StudentID
• ApplicationID
• ...

я должен избавиться от ApplicationID в таблице приложения и использовать JobId и StudentID в качестве составного первичного ключа или я должен использовать их как внешние ключи и использовать ApplicationID в качестве первичного ключа?

Примечание: Если это имеет значение, я буду претендуете ограничения, такие, как студенты могут принимать только одно приложение, есть 3 недели после него предлагается принять его и т.д.

Благодаря

Answer 1

С теоретической точки view, первичный ключможет показаться излишним на данном этапе (учитывая, что есть только эти 3 таблицы), поэтому у вас может возникнуть соблазн отказаться от него и переключиться на более естественный составной первичный ключ (StudentID, JobID).

Однако, есть 2 сильных практических аргумента против этого.

1. Ваша структура данных может вырасти за эти 3 таблицы, и в какой-то момент сам Application таблицу можно ссылаться из другого. Это означает, что каждый внешний ключ, ссылающийся на этот стол, также должен быть составным и состоять из комбинации StudentID и JobID, везде.

2. Каждое приложение за пределами уровня SQL должно отображать таблицу Application на основе этого составного первичного ключа, чтобы просматривать/редактировать или удалять записи из него.

Вам решать, насколько сильны эти 2 балла, для вашего конкретного случая. Если вероятность того, что таблица Application будет указана, имеет тенденцию к 0, и вы не планируете управлять ею через верхний уровень программного обеспечения, тогда сложный первичный ключ является способом перехода. Во всех остальных случаях я бы выбрал один первичный ключ ApplicationID и имел дополнительное уникальное ограничение по сравнению с (StudentID, JobID).