Повторяющиеся первичные ключи в отношениях «многие ко многим»

Question

Между двумя таблицами tArticle и tCustomer существует связь am: n. Всякий раз, когда покупатель покупает товар, в третьей таблице сохраняется ссылка между товаром и покупателем с дополнительным атрибутом, в котором указывается сумма, которую покупатель купил.

tArticle:

kArticle | title | stock
---------+-------+------
1        | Water | 39
2        | Apple | 14

tCustomer:

kCustomer | surname | firstName
----------+---------+----------
1         | Muller  | Max
2         | Meier   | Tom

tCustomer_tArticle:

kCustomer | kArticle | number
----------+----------+---------
1         | 2        | 2
2         | 2        | 5
2         | 2        | 3

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

Теперь у меня вопрос: нужно ли добавить первичный ключ AUTO_INCREMENT в третью таблицу или использовать физический порядок для получения уникальных записей?

Мой второй вопрос: есть лиспособ указать в диаграмме отношений сущности, может ли ссылка в отношении am: n появляться дважды.

Answer 1

Я не знаю, где "настоятельно рекомендуется", чтобы два внешних ключа были первичными ключами. Это определенно один подход при правильных обстоятельствах. Я предпочитаю подход всегда присваивать таблице уникальный автоинкрементный ключ, если только не возникает проблема с нехваткой места. Автоинкрементные ключи предоставляют:

• Уникальные ссылки на каждую строку для update с и delete с.
• Запись порядка вставки.
• Возможность объявления более простых внешних ключей для таблицы.

По сути, ваша таблица является таблицей транзакций. Я бы порекомендовал не только автоинкрементный ключ, но также дату / время транзакции и, возможно, другую информацию.

Что касается этого комментария:

или я должен использовать физический порядок дляимеют уникальные записи.

Таблицы SQL представляют неупорядоченные наборы. Там нет физического порядка, который вы должны увидеть полезным для доступа к строкам. Если вы заботитесь о порядке вставки, то вам действительно нужен автоматически увеличиваемый ключ.

Answer 2

Подумайте, какую информацию вы пытаетесь представить в таблице tCustomer_tArticle. Например, в следующем случае:

kCustomer | kArticle | number
----------+----------+---------
2         | 2        | 3
2         | 2        | 3

Означает ли это, что Том купил шесть яблок, или это означает, что было две транзакции, каждая из которых состояла из трех яблок? Если предполагается, что таблица просто является записью количества, то вы можете сделать kCustomer, kArticle ключом и записать одну и ту же информацию в одну строку:

kCustomer | kArticle | number
----------+----------+---------
2         | 2        | 6

Если в таблице предполагается записать отдельное транзакции тогда кажется, что в таблице отсутствует информация. Исходя из вашего исходного примера с тремя строками примеров данных, возможно, неясно, будет ли это одна, две или три транзакции. Я ожидаю, что в составном ключе будет какой-то идентификатор транзакции. Я не думаю, что автоматически увеличивающееся число поможет. Прежде чем подумать о добавлении суррогатных ключей, необходимо определить значимый ключ, который имеет смысл для бизнес-сферы.

Answer 3

«Теперь у меня вопрос: нужно ли мне добавить первичный ключ AUTO_INCREMENT в третью таблицу или я должен использовать физический порядок, чтобы иметь уникальные записи?»

Что вы подразумеваете под "физическим порядком иметь уникальные записи"?

В вашем случае я предлагаю добавить AUTO_INCREMENT PK , скажем:

order_id PRIMARY KEY AUTO_INCREMENT

Моя причина такова: подумайте, когда вы пойдете в McDonald's, вы получите квитанцию ​​с идентификатором заказа. когда вы снова приобретете еду, вы получите другой идентификатор заказа в новой квитанции. Таким образом, атрибут order_id делает каждый заказ уникальным.

"если есть способ указать в диаграмме отношений сущностей, может ли ссылка в отношении am: n появляться дважды"

НасколькоЯ знаю, нет. Я предполагаю, что вы хотите, чтобы ваша модель ER отражала, сколько раз (или клиент мог купить один и тот же товар более одного раза), если это так, вы можете подумать над этим вопросом следующим образом:

Could tCustomer_tArticle(order_id, kCustomer, kArticle, number) отразить эту функцию? Да. мы можем сделать:

SELECT order_id,kCustomer,kArticle,number FROM tCustomer_tArticle WHERE kCustomer="Tom";

Это даст нам результат того, сколько заказов сделал Том.

Пока у вас есть PK для указания каждого заказа, вы получите ответ своегоВторой вопрос.