Несколько внешних ключей на запись в sql?

Question

Я создаю приложение (использующее PHP / Codeigniter / MYSQL) для отслеживания добровольцев на мероприятиях.Я бы хотел, чтобы несколько волонтеров могли подписаться на каждое событие.Я планирую сделать это, используя таблицу с именем signup, которая выглядит примерно так:

TABLE SIGNUP
============

VolunteerId         EventId
-----------         -------
    12                223
    13                223
    15                223
    12                235
    13                235
    19                235

Оба столбца являются внешними ключами (для первичных ключей таблицы volunteer и event соответственно).

Есть ли лучший способ сделать это?Должен ли я использовать составной ключ в качестве первичного ключа?

Answer 1

Честно говоря, я не вижу проблемы с тем, как вы это настроили.Подобные таблицы обычно используются для установления отношений «один ко многим» между различными объектами.Я делаю нечто подобное в таблице, которая ссылается на графства и города в данном штате.(Некоторые города охватывают несколько округов.)

В рекомендациях по проектированию базы данных говорится, что вы должны объявить первичный ключ для таблицы.Вам не нужно делать это;технически вы можете объявить таблицу без первичного ключа.Тем не менее, обратите внимание, что многие механизмы БД просто создадут первичный ключ для вас за кулисами, если вы специально не объявите ключ;это, однако, не может быть идеальным для каждой ситуации (и, как правило, не так).Указание первичного ключа по вашему выбору хорошо для оптимизации базы данных и организации.

В связи с этим я бы сказал, что вы также можете использовать составной ключ в качестве первичного ключа для таблицы «многие ко многим».вместо создания отдельного столбца индекса.В этой ситуации это удовлетворит требования к таблице (так как механизм БД сделает для вас первичный ключ независимо от этого) и предотвратит множественные вхождения одной и той же пары, что не принесет вам пользы во многих многим.справочная таблица.

Краткий ответ: перейти с составного первичного ключа - primary key(VolunteerID, EventID).Вы не должны ошибаться.

Answer 2

Одно из применений составного УНИКАЛЬНОГО ключа - предотвратить повторное появление одной и той же пары добровольец / событие в таблице.Для этого не требуется первичный ключ.

Answer 3

Учитывая таблицу, которую вы описали, у вас есть три варианта

1 - lunchmeat317

SIGNUP
-------
VolunteerId (PK)
EventId (PK)

2 - Тед Хопп

SIGNUP
-------
VolunteerId (AK1)
EventId (AK1)

3 - ic3b3rg

SIGNUP
-------
SignUpID (PK)
VolunteerId (AK1)
EventId (AK1)

Как отметил Томас, основное различие между 1 и 2 состоит в том, что Unique не останавливает следующее.

   VolunteerId EventId
   ----------- -------
   null        null
   null        null

Однако если эти поля не позволяют начинать с нуля (а не должны), то они точно такие же.

Вы также можете добавить, поскольку ic3b3rg предлагает суррогатный ключ (SignUpID). Но, как отмечает CJ Date (и я перефразирую), введение искусственного, суррогатного, нелетучего ключа часто будет хорошей идеей, но поскольку зачастую трудно определить изменчивость, нет формального способа узнать, когда вы действительно нужно это.

Тем не менее, пока эта таблица ...

• Отслеживание того, что волонтеры подписались на мероприятия
• Не будет никаких других атрибутов, которые имеют функциональную зависимость или зависимость соединения от R (VolunteerId, EventID)

... тогда в бессмертных словах Йоги Берры " Когда вы придете к развилке дороги, возьмите его " Это означает, что все три варианта верны и выбор, вероятно, не повлияет на вашу систему так или иначе.

Лично я обычно так делаю.

SIGNUP
-------
SignUpID (PK)
VolunteerId (AK1) (Not Null)
EventId (AK1) (Not Null)

Answer 4

Хорошее обсуждение того, почему следует избегать составных первичных ключей: Каковы недостатки использования составного / составного первичного ключа?