Да използвате съставен ключ като първичен ключ или да имате 2 външни ключа и друго отделно поле като първичен ключ?

Имам следните таблици:

| студент |

  • ID на студент(P)
  • Име
  • ...

| Работа |

  • JobID(P)
  • Job_Name
  • ...

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

  • JobID
  • ID на студент
  • ApplicationID
  • ...

трябва ли да се отърва от ApplicationID в таблицата Application и да използвам JobID и StudentID като съставен първичен ключ или трябва да ги имам като външни ключове и да използвам ApplicationID като първичен ключ?

забележка: Ако има значение, ще прилагам ограничения, като студентите могат да приемат само едно заявление, да имат 3 седмици, след като то бъде предложено, за да го приемат и т.н.

Благодаря


postgresql sql primary-key foreign-keys composite-key
person JabbaWook    schedule 08.12.2014    source източник
comment
Като се има предвид, че таблицата с приложения може също да бъде препратена от някъде другаде в даден момент, бих запазил единичния 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).

Има обаче 2 силни практически контрааргумента за това.

  1. Вашата структура от данни може да надхвърли тези 3 таблици и в даден момент самата таблица Application може да бъде препратена от някъде другаде. Това би означавало, че всеки външен ключ, препращащ към тази таблица, също трябва да бъде съставен и да се състои от комбинацията StudentID и JobID навсякъде.

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

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

person Kouber Saparev    schedule 08.12.2014
comment
Има и трета причина (IMHO): в бъдеще може да е необходима допълнителна ключова колона start_date в таблицата за кандидатстване, за да позволи на едно и също лице да получи работата, да я напусне и да бъде наето отново. - person joop; 08.12.2014
comment
Наистина, това изглежда като напълно валиден сценарий, който поставя под въпрос дори уникалността на комбинацията (StudentID, JobId). - person Kouber Saparev; 08.12.2014
comment
{studentId, JobId, start_date} ще формира естествен PK. (но може да се натъкнете на проблеми с NULLability за двата FK; най-добре е да ги дефинирате NOT NULL така или иначе) (и/или евентуално да запазите сурогата, за да позволите бъдещи ключови актуализации в {studentId, JobId, start_date}) - person joop; 08.12.2014