Любой пример нужного внешнего ключа?

Customers
 customer_id

Orders
 order_id
 customer_id fk

Если у меня есть две таблицы и определить внешний ключ в customer_id в таблице Orders, разрешив ей значение null, я говорю, что у меня может быть заказ, у которого нет связанного с ним клиента. Таким образом, понятие обнуляемого внешнего ключа, по-видимому, противоречит цели внешнего ключа, который заключается в обеспечении соблюдения этого ограничения.

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

Ответ 1

Представьте таблицу, содержащую TODO команды. Если TODO еще не назначен члену команды, его user_id составляет NULL. Если это не NULL, это внешний ключ для таблицы users.

Ответ 2

Нет, нулевые внешние ключи никогда не нужны.

Вы всегда можете нормализовать необязательные отношения 1-много. Взяв ваш пример, вы можете иметь следующие таблицы:

Customers: customer_id, ...
Orders: order_id, ...
OrdersCustomers: order_id, customer_id
  UNIQUE(order_id)

Два уникальных ограничения гарантируют, что один заказ может принадлежать только одному клиенту и никогда не к одному клиенту дважды.

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

Ответ 3

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

Целью внешнего ключа является то, что явное понятие случайное целое в таблице Orders фактически ссылается на элемент в таблице Customers. Фактически принудительное выполнение этого ограничения является случайным.

Ответ 4

Чтобы установить внешний ключ с нулевым значением или использовать значение null ниже sql script

ALTER TABLE Return_COMMENTS MODIFY order_ID Number NULL;

Ответ 5

есть, создайте некоторую древовидную структуру, таблицу, связанную с собой. Рассмотрим это:

table_node(node_id, parent_node_id, name)

Для корня parent_node_id должен иметь значение null, правильно?

Ответ 6

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

Когда родительская запись (например, учетная запись) имеет дочерние элементы, которые могут быть удалены (например, запросы справки), это хорошее использование.

У вас может быть столбец для MostRecentRequest, который содержит идентификатор самого последнего запроса справки. Когда запрос удаляется из системы, столбцу MostRecentRequest присваивается значение NULL, что означает, что его нет.

Другим примером является то, что вы хотите, чтобы NULL означал, что строке еще не присвоен родитель. Возможно, у вас есть запросы на помощь, которые входят в систему, и NULL в поле техник означает, что никому не назначен запрос. Когда вы удалите этого техника, вы хотите, чтобы вся его незавершенная работа вернулась в пул, сбросив значение до NULL.

Ответ 7

У нас есть много таких вещей, поскольку наше приложение - это то, что начинается с некоторой базовой информации для события и со временем, так как мероприятие более полно запланировано, добавлена дополнительная информация. Но когда информация добавлена, мы хотим убедиться, что она соответствует ограничению FK. FKs предназначены для целостности данных, но все данные не всегда известны во время ввода исходных данных, поэтому допускаются значения NULL.

Ответ 8

Есть еще одна ситуация, о которой я могу думать:

В одной таблице у вас есть поле идентификатора, которое однозначно идентифицирует эту запись. Эта же запись может (или не иметь) иметь одного родителя.

Таблица со следующими столбцами:

id как целое число, auto-increment, not nullable
parentid как целое число, nullable.

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