Любой пример нужного внешнего ключа?
Customers customer_id Orders order_id customer_id fk Если у меня есть две таблицы и определить внешний ключ в customer_id в таблице Orders, разрешив ему значение null, я говорю, что у меня может быть заказ, у которого нет связанного с ним клиента. Таким образом, понятие обнуляемого внешнего ключа, по-видимому, противоречит цели внешнего ключа, который заключается в обеспечении соблюдения этого ограничения.
Есть ли простой пример ситуации, в которой необходим нулевой внешний ключ? Или аргумент в пользу их разрешения?
Представьте таблицу, которая содержит TODO команды. Если TODO еще не назначен члену команды, его user_id имеет NULL . Если это не NULL это внешний ключ для таблицы users .
Нет, нулевые foreign keys никогда не нужны .
Вы всегда можете нормализовать необязательные отношения 1-много. Взяв ваш пример, у вас могут быть следующие таблицы:
Customers: customer_id, ... Orders: order_id, ... OrdersCustomers: order_id, customer_id UNIQUE(order_id)
Два уникальных ограничения гарантируют, что один заказ может принадлежать только одному клиенту, а не одному клиенту.
Всегда ли нормализовать такие отношения, это совсем другая история. В некоторых случаях денормализация может привести к более простым реализациям.
Таким образом, понятие обнуляемого внешнего ключа, по-видимому, противоречит цели внешнего ключа, который заключается в обеспечении соблюдения этого ограничения.
objectiveю внешнего ключа является то, что в явном виде понятие случайное целое в таблице Orders фактически ссылается на элемент в таблице Customers. Фактически принудительное применение этого ограничения является случайным.
Чтобы установить внешний ключ с нулевым значением или использовать значение null ниже sql-скрипта
ALTER TABLE Return_COMMENTS MODIFY order_ID Number NULL;
есть, сделать некоторую древовидную структуру, таблицу, которая связана с собой. Учти это:
table_node(node_id, parent_node_id, name)
Для корня parent_node_id должен иметь значение null, не так ли?
Общий сценарий проектирования для установки столбца в нуль – это если у вас есть одно-много родительских дочерних отношений, но дети не обязательно должны присутствовать.
Когда родительская запись (например, учетная запись) имеет детей, которые могут быть удалены (например, запросы справки), это хорошее использование.
У вас может быть столбец для MostRecentRequest, который включает идентификатор последнего запроса справки. Когда запрос удаляется из системы, в столбце MostRecentRequest установлено значение NULL, что означает, что нет ни одного присутствующего.
Другим примером является то, что вы хотите, чтобы NULL означал, что группе еще не назначен родитель. Возможно, у вас есть запросы на помощь, которые входят в систему, и NULL в поле техник означает, что никому не назначен запрос. Когда вы удалите этого техника, вы хотите, чтобы вся его незавершенная работа вернулась в пул, сбросив значение до NULL.
Есть еще одна ситуация, о которой я могу думать:
Внутри одной таблицы у вас есть поле идентификатора, которое однозначно идентифицирует эту запись. Эта же запись может (или не иметь) иметь одного родителя.
Таблица со следующими столбцами:
- id как целое число, auto-increment, не может быть NULL
- parentid как целое число, nullable.
С ограничением внешнего ключа вы можете убедиться, что если поле не равно null, оно ссылается на действительного родителя. Кроме того, если вы попытаетесь удалить родительскую запись без фиксации дочерних элементов, родительский элемент не может быть удален.
У нас есть много таких вещей, поскольку наше приложение – это то, что начинается с некоторой базовой информации для события и со временем, поскольку мероприятие более полно запланировано, добавлена дополнительная информация. Но когда информация добавлена, мы хотим убедиться, что она соответствует ограничению FK. FK предназначены для целостности данных, но все данные не всегда известны во время ввода исходных данных, поэтому допустимы значения NULL.