Могу ли я иметь один столбец для двух разных значений с внешним ключом из двух разных таблиц?

Question

Итак, у меня есть эта таблица Адреса :

CREATE TABLE Addresses
(
Address_ID VARCHAR (10) PRIMARY KEY,
Student_ID/Staff_Number VARCHAR (20),
Name CHAR (50),
Surname CHAR (30),
Building/House_Number INT (5),
Street CHAR (20),
City CHAR (30),
Postcode VARCHAR (10)
FOREIGN KEY (Student_ID) REFERENCES Students (Student_ID)
);

Дело в том, что строка Student_ID/Staff_Number VARCHAR (20), идет либо из таблицы студентов, либо из таблицы персонала.Так можно ли назначить два внешних ключа?

Answer 1

Вы всегда можете добавить несколько ограничений внешнего ключа для одного столбца, но ALL из них будут применены, а не только один из них.Например:

CREATE TABLE Addresses
(
Address_ID VARCHAR (10) PRIMARY KEY,
Student_ID VARCHAR (20),
Name CHAR (50),
Surname CHAR (30),
Building/House_Number INT (5),
Street CHAR (20),
City CHAR (30),
Postcode VARCHAR (10),
FOREIGN KEY (Student_ID) REFERENCES Students (Student_ID)
FOREIGN KEY (Student_ID) REFERENCES Staff (Staff_ID)
);

Это, вероятно, не то, что вы хотите.Возможно, вам нужно иметь два столбца, каждый из которых указывает на отдельную таблицу;а для столбцов один всегда равен null, а другой не равен нулю.Вы можете сделать это, как показано ниже:

CREATE TABLE Addresses
(
Address_ID VARCHAR (10) PRIMARY KEY,
Student_ID VARCHAR (20),
Staff_ID VARCHAR(20),
Name CHAR (50),
Surname CHAR (30),
Building/House_Number INT (5),
Street CHAR (20),
City CHAR (30),
Postcode VARCHAR (10),
FOREIGN KEY (Student_ID) REFERENCES Students (Student_ID),
FOREIGN KEY (Staff_ID) REFERENCES Staff (Staff_ID),
constraint ct1 check (Student_ID is null and Staff_ID is not null
                   or Student_ID is not null and Staff_ID is null)
);

Ограничение ct1 гарантирует, что один и только один из них является "активным" в любой данный момент времени.

Answer 2

Хорошо, это меньше "как мне сделать конкретную вещь Х?" и еще "Как должен я буду делать это?"

Потому что, честно говоря, вы не хотите делать это так, как вы пытаетесь выложить.

Позвольте мне дать вам несколько альтернатив, которые лучше с точки зрения структуры базы данных:

1. Поменяйте отношения (моя рекомендация). Вместо таблицы адресов, привязывающей сотрудников / студентов, попросите сотрудников / студентов привязка к AddressID.
2. Объедините две таблицы в таблицу персон (еще один очень хороший выбор). Таким образом, у вас есть только одна таблица, на которую ссылается таблица адресов. Затем, если определенные поля применимы только к одному типу человека (только для персонала, только для студентов и т. Д.) - выгрузите только эти столбцы в выделенную таблицу только для этих полей. Таким образом, у вас может быть таблица Person со всей базовой информацией, таблица Address, которая связана с таблицей Person, таблица Student с столбцом GradeLevel и таблица Staff с столбцом SubjectTaught.
3. Есть две отдельные таблицы адресов: одна для студентов, другая для персонала. Хотите связать таблицу учеников? Отлично - ты получил StudentID в таблице StudentAddress. И то же самое с Посох.
4. Есть столбец, указывающий тип адресата. 0 для студентов, 1 для персонала. Ни в коем случае не устанавливайте ограничение внешнего ключа.
5. Имеют два отдельных столбца - один для идентификатора студента, один для идентификатора персонала (предположительно, один всегда будет нулевым.) Сделайте их обоих внешний ключ к соответствующей таблице (внешние ключи могут иметь значение null значения.)

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

Answer 3

Нет, это невозможно.

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

PS Являются ли ваши столбцы идентификаторов varchar кластеризованными индексами?Это может сказаться на производительности, рассмотрите столбец суррогатных идентификаторов для кластеризации