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

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

| студент |

  • идентификатор студента (P)
  • Имя
  • ...

| Вакансии |

  • Идентификатор задания(P)
  • Название работы
  • ...

| Приложение |

  • Идентификатор задания
  • Студенческий билет
  • ID приложения
  • ...

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

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

Спасибо


postgresql sql primary-key foreign-keys composite-key
person JabbaWook    schedule 08.12.2014    source источник
comment
Учитывая, что в какой-то момент на таблицу Application также можно ссылаться откуда-то еще, я бы сохранил единственный идентификатор PK ApplicationID.   -  person Kouber Saparev    schedule 08.12.2014
comment
круто, спасибо - @KouberSaparev, если вы поставите в качестве ответа, я проголосую за ответ?   -  person JabbaWook    schedule 08.12.2014

Ответы (1)


arrow_upward
1
arrow_downward

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

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

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

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

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

person Kouber Saparev    schedule 08.12.2014
comment
Есть и третья причина (ИМХО): в будущем может понадобиться дополнительный ключевой столбец start_date в таблице заявок, чтобы один и тот же человек мог получить работу, уволиться и снова быть нанятым. - person joop; 08.12.2014
comment
В самом деле, это выглядит вполне допустимым сценарием, который ставит под сомнение даже уникальность комбинации (StudentID, JobId). - person Kouber Saparev; 08.12.2014
comment
{studentId, JobId, start_date} образует естественный ПК. (но вы можете столкнуться с проблемами NULLability для двух FK, лучше всего определить их NOT NULL в любом случае) (и/или, возможно, сохранить суррогат, чтобы разрешить будущие обновления ключа в {studentId, JobId, start_date} ) - person joop; 08.12.2014