Должны ли таблицы соединений иметь более одного первичного ключа из другой идентификационной таблицы?

Question

Вот пример: Первоначально у меня есть 3 таблицы. Таблица B ссылается на таблицу A. Итак, теперь таблица B имеет два первичных ключа. Один из них используется в качестве исходного первичного ключа, а другой - для обеспечения его связи с Tabe A. Затем я хочу, чтобы у таблицы B была связь «многие ко многим» с таблицей X. По мере добавления отношения MySQL Workbench добавлял таблицу Y с обоими первичными ключами таблицы B и одним первичным ключом в таблице X. Таким образом, таблица Y теперь имеет три первичных ключа.

Кажется, что второй первичный ключ из таблицы B в соединительной таблице не нужен, поскольку я могу идентифицировать таблицу B с исходным первичным ключом. Итак, мне все еще нужен дополнительный первичный ключ? Или, возможно, у меня не должно быть неопределенных отношений между таблицей A и B?

Таблица A и B имеют отношения, примерно такие, как у пользователя много сообщений. Сообщение должно принадлежать пользователю. Но у Post уже есть собственный первичный ключ, поэтому должен ли внешний ключ для пользователя быть первичным ключом?

EDIT

Вот сценарий (ссылка на схему ниже). Таблицы, на которых я сосредотачиваюсь, это snippet, snippet_topic и tag. Из того, что я знаю, поскольку каждый фрагмент должен принадлежать snippet_topic, он имеет идентифицирующую связь. Поэтому я использовал идентификационные отношения в MySQL Workbench, и они добавили идентификатор snippet_topic в качестве первичного ключа. После этого я добавил отношение m: n для тега и фрагмента. MySQL Workbench добавил идентификатор snippet_topic в таблицу соединений (но я его удалил). Что-то не так с моим дизайном? Или есть более правильный путь к этому?

Легенда: Желтый значок - первичный ключ Красный значок - не ноль

Answer 1

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

Answer 2

Первоначально у меня есть 3 таблицы.

Хорошо.

Таблица B ссылается на таблицу A. Итак, теперь Таблица B имеет два основных ключа. Один использовал в качестве исходного первичного ключа и другой, чтобы обеспечить свои отношения с табе А.

Нет. Таблица B имеет один первичный ключ и один внешний ключ. Внешний ключ может быть частью первичного ключа, а может и не быть.

Тогда я хочу, чтобы Таблица B имела отношения многие ко многим с таблицей X.

Хорошо.

Когда я добавляю отношения, MySQL Workbench добавил таблицу Y с обоими Первичные ключи таблицы B и один первичный ключ в таблице X. Таким образом, таблица Y теперь имеет три первичных ключа.

Отношение «многие ко многим» обычно реализуется в виде таблицы, содержащей два внешних ключа в качестве первичного ключа. В вашем случае один внешний ключ является первичным ключом таблицы B, а другой внешний ключ является первичным ключом таблицы X. Кажется, что первичный ключ таблицы B содержит два столбца. Таблицы могут выглядеть следующим образом.

• Таблица A: { a ₁ , a ₂ }
• Таблица B: { b ₁ , a ₁ , b ₂ , b ₃ }, a ₁ ссылки Таблица A
• Таблица X: { x ₁ , x ₂ }

Таблица Y, которая реализует отношение m: n, содержит ключи от B и от X.

• Таблица Y: { b ₁ , a ₁ , x ₁ }, два столбца b ₁ , a ₁ , справочная таблица B; столбец x ₁ ссылки Таблица X

Если вы хотите получить лучшие ответы, отредактируйте свой вопрос и включите SQL DDL для своих таблиц. Получить DDL можно с помощью SHOW CREATE TABLE .

Answer 3

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

Answer 4

Вы не можете иметь более одного первичного ключа .То, что у вас есть, может быть индексами .Если в ваш первичный ключ включен столбец user_id из таблицы posts, вы можете вынуть его и оставить первичный ключ, состоящий только из столбца id.

Надеюсь, это поможет