один и тот же внешний ключ для двух разных первичных ключей

Question

один и тот же внешний ключ для двух разных первичных ключей

0

моя проблема в том, что я не знаю, и я не могу понять, возможно ли иметь два разных первичных ключа, ссылающихся на один и тот же ключ foreighn. Чтобы быть более конкретным, у меня есть три таблицы. Первая таблица называется персоналом с атрибутами: id fname lname password. Вторая таблица называется учеником с атрибутами: id fname lname password role и, наконец, третья таблица, которая называется сообщением, и имеет 4 атрибута: id text date user_fk и я хочу, чтобы два первичных ключа ссылались на ключ foreighn. В phpmyadmin довольно легко, и я это сделал. Проблема в том, что когда я хочу ввести новую строку, база данных, я полагаю, не может понять, является ли первичный ключ из таблицы сотрудников или студента. Сообщение, которое я получаю: #1452 - Cannot add or update a child row: a foreign key constraint fails ( дисс . Сообщение , CONSTRAINT student_fk FOREIGN KEY ( user_fk ) REFERENCES студент ( studentid )). Поэтому мой вопрос: совершенно ли неправильно, что я хочу делать? Может быть, лучше создать, например, другую таблицу, в которой будут храниться только ключи foreighn? Или ошибка где-то еще, что я не могу ее найти? Спасибо!

EdwardCooper 13 сен. 2018, в 18:39

Источник

0

почему бы не создать 2 внешних ключа? и для ошибки значение должно существовать в таблицах персонала и ученика (если это правда, что DBM принял их оба на этапе создания)
lagripe 13 сен. 2018, в 16:20
1

Вы не можете иметь миграционный внешний ключ - тот, который берет идентификатор из любой из двух таблиц. Сказать, что вы хотите, чтобы два первичных ключа указывали на один и тот же внешний ключ, сбивает с толку. Кроме того, как сотрудники, так и студенты являются типами людей. Плохо практиковать перечисление ролей в виде таблиц, в этом случае вам не нужно делать то, что вы предлагаете. Персона: id, fname, lname, passowrd роль (студент, персонал). Сообщение: id, текст, дата, person_fk. Роль присуща личности человека, который мигрирует через FK.
T Gray 13 сен. 2018, в 16:38
0

@TGray Спасибо за ваш ответ, я могу понять вашу точку зрения, но в будущем сотрудники будут делать разные вещи из ученика. Например, сотрудники могут вставить нового учащегося или загрузить текст, где каждый идентификатор сотрудника будет связан с текстом. Является ли хорошей практикой иметь все в одном столе, и студентов, и персонал, и все будет зависеть от атрибута 'роль'?
EdwardCooper 13 сен. 2018, в 20:24
0

@EdwardCooper Вообще говоря, перечисление ролей или типов через структуру оставляет вам необходимость делать такие вещи, как внешние объединения. Кроме того, текст должен быть в своей собственной таблице с чем-то вроде даты эффективности или типа supercedes_by_id, если они должны быть пересмотрены. Я бы избегал перечисления через структуру практически любой ценой. Моя текущая среда (не мой дизайн) требует 29 внешних соединений, чтобы идентифицировать одну вещь. Семантика важна. Кажется, есть желание нарушать нормальные формы повсюду.
T Gray 14 сен. 2018, в 15:38
0

@ EdwardCooper И единственное место, о котором никогда не думают о нарушениях, это «ну, может быть несколько разных вещей для этой вещи, в отличие от этого». Возьмите кредитные карты, например. Все они семантически идентичны (даже если для определенных карт может потребоваться что-то другое, например, длина кода CVV). Если бы у каждой кредитной карты был свой собственный стол (AMEX, Visa, MC, Discover, Diners, yadayada), вам нужно было бы выполнить n-way external join, чтобы выяснить, из какой таблицы вытащить. Плохая идея. Просто добавьте тип (если хотите - каждый тип CC начинается с другого номера).
T Gray 14 сен. 2018, в 15:42
0

@TGray Хмм, я могу понять вашу точку зрения. Но в этой ситуации я хотел сделать что-то, и я забыл упомянуть, что это чат между студентами и персоналом, где каждый текст будет вставлен в таблицу с указанными выше атрибутами. Вот почему я хочу, чтобы два первичных ключа ссылались на один и тот же ключ. Для того, чтобы узнать, кто «загрузил» сообщение, даже студент или сотрудник. Итак (еще раз хочу поблагодарить вас за ваши ответы, они действительно помогли мне), какой лучший способ реализовать что-то подобное, потому что это действительно смущает меня?
EdwardCooper 14 сен. 2018, в 17:09
0

Я понимаю, что вы хотите. А то, что вы хотите, не работает. Нет никакого способа создать внешний ключ, который получает свое значение из двух разных таблиц. Семантически нет никакой разницы между студентом и сотрудником, кроме роли. Желаю тебе удачи.
T Gray 18 сен. 2018, в 03:11

Показать ещё 5 комментариев

Теги:

mysql

database

sql

1 ответ

Ещё вопросы

почему бы не создать 2 внешних ключа? и для ошибки значение должно существовать в таблицах персонала и ученика (если это правда, что DBM принял их оба на этапе создания)
Вы не можете иметь миграционный внешний ключ - тот, который берет идентификатор из любой из двух таблиц. Сказать, что вы хотите, чтобы два первичных ключа указывали на один и тот же внешний ключ, сбивает с толку. Кроме того, как сотрудники, так и студенты являются типами людей. Плохо практиковать перечисление ролей в виде таблиц, в этом случае вам не нужно делать то, что вы предлагаете. Персона: id, fname, lname, passowrd роль (студент, персонал). Сообщение: id, текст, дата, person_fk. Роль присуща личности человека, который мигрирует через FK.
@TGray Спасибо за ваш ответ, я могу понять вашу точку зрения, но в будущем сотрудники будут делать разные вещи из ученика. Например, сотрудники могут вставить нового учащегося или загрузить текст, где каждый идентификатор сотрудника будет связан с текстом. Является ли хорошей практикой иметь все в одном столе, и студентов, и персонал, и все будет зависеть от атрибута 'роль'?
@EdwardCooper Вообще говоря, перечисление ролей или типов через структуру оставляет вам необходимость делать такие вещи, как внешние объединения. Кроме того, текст должен быть в своей собственной таблице с чем-то вроде даты эффективности или типа supercedes_by_id, если они должны быть пересмотрены. Я бы избегал перечисления через структуру практически любой ценой. Моя текущая среда (не мой дизайн) требует 29 внешних соединений, чтобы идентифицировать одну вещь. Семантика важна. Кажется, есть желание нарушать нормальные формы повсюду.
@ EdwardCooper И единственное место, о котором никогда не думают о нарушениях, это «ну, может быть несколько разных вещей для этой вещи, в отличие от этого». Возьмите кредитные карты, например. Все они семантически идентичны (даже если для определенных карт может потребоваться что-то другое, например, длина кода CVV). Если бы у каждой кредитной карты был свой собственный стол (AMEX, Visa, MC, Discover, Diners, yadayada), вам нужно было бы выполнить n-way external join, чтобы выяснить, из какой таблицы вытащить. Плохая идея. Просто добавьте тип (если хотите - каждый тип CC начинается с другого номера).
@TGray Хмм, я могу понять вашу точку зрения. Но в этой ситуации я хотел сделать что-то, и я забыл упомянуть, что это чат между студентами и персоналом, где каждый текст будет вставлен в таблицу с указанными выше атрибутами. Вот почему я хочу, чтобы два первичных ключа ссылались на один и тот же ключ. Для того, чтобы узнать, кто «загрузил» сообщение, даже студент или сотрудник. Итак (еще раз хочу поблагодарить вас за ваши ответы, они действительно помогли мне), какой лучший способ реализовать что-то подобное, потому что это действительно смущает меня?
Я понимаю, что вы хотите. А то, что вы хотите, не работает. Нет никакого способа создать внешний ключ, который получает свое значение из двух разных таблиц. Семантически нет никакой разницы между студентом и сотрудником, кроме роли. Желаю тебе удачи.

Rohit · Answer 1 · 2018-09-13T14-12-00.000Z

Если я правильно вас понимаю, внешний ключ user_fk в message относится к идентификаторам student и staff.

В этом случае, если вы попытаетесь вставить данные в таблицу message, он проверит обе таблицы student и staff для этого идентификатора. Отсюда и ошибка.

Что вы можете сделать, так это добавить два столбца внешнего ключа в message 1 для каждой таблицы.

Обновить

Вышеупомянутый подход приведет к возможности обнуления внешних ключей. Вместо этого мы можем иметь две таблицы отображения по одному для каждой таблицы. например: student_message_map и staff_message_map. Каждая таблица будет содержать 2 внешних ключа student_id и message_id/staff_id и message_id.

Это приведет к тому, что столбцы будут недействительными, но для запросов потребуется выполнить два объединения. Кроме того, кто-то, смотрящий на эти отношения, может подумать, что многие отношения многие из-за таблиц сопоставления.

ИМО с нулевым внешним ключом - это не плохая практика, вам просто нужно знать во время запросов, о возможности нулевых значений.

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