Пожалуйста, уточните две вещи для меня:
- Может ли внешний ключ быть пустым?
- Может ли внешний ключ быть дублированным?
Насколько я знаю, NULL
его нельзя использовать во внешних ключах, но в некоторых моих приложениях я могу вводить данные NULL
как в Oracle, так и в SQL Server, и не знаю почему.
sql
sql-server
oracle
foreign-keys
джемы
источник
источник
Ответы:
Краткий ответ: Да, это может быть NULL или дубликат.
Я хочу объяснить, почему внешний ключ может быть нулевым или уникальным или не уникальным. Во-первых, помните, что внешний ключ просто требует, чтобы значение в этом поле сначала существовало в другой таблице (родительской таблице). Это все ФК по определению. Ноль по определению не является значением. Нуль означает, что мы еще не знаем, какова стоимость.
Позвольте мне привести пример из жизни. Предположим, у вас есть база данных, в которой хранятся коммерческие предложения. Предположим далее, что каждому предложению назначен только один продавец и один клиент. Таким образом, ваша таблица предложений будет иметь два внешних ключа, один с идентификатором клиента и один с идентификатором торгового представителя. Однако во время создания записи торговый представитель не всегда назначается (поскольку никто еще не может работать над ней), поэтому идентификатор клиента заполнен, но идентификатор торгового представителя может быть нулевым. Другими словами, обычно вам нужна возможность иметь нулевой FK, когда вы можете не знать его значение во время ввода данных, но вы знаете другие значения в таблице, которые необходимо ввести. Чтобы разрешить нулевые значения в FK, как правило, все, что вам нужно сделать, это разрешить нулевые значения в поле, в котором есть FK. Нулевое значение отличается от идеи, что это FK.
Является ли он уникальным или не уникальным, зависит от того, имеет ли таблица отношение «один-один» или «один-много» к родительской таблице. Теперь, если у вас есть отношение один к одному, возможно, что вы могли бы хранить все данные в одной таблице, но если таблица становится слишком широкой или если данные по другой теме (сотрудник - пример страхования @tbone дал например), то вы хотите отдельные таблицы с FK. Затем вы захотите сделать этот FK либо PK (который гарантирует уникальность), либо наложить на него уникальное ограничение.
Большинство FK предназначены для отношений один-ко-многим, и это то, что вы получаете от FK без добавления дополнительных ограничений на поле. Таким образом, у вас есть таблица заказа и таблица деталей заказа, например. Если клиент заказывает десять товаров за один раз, у него есть один заказ и десять подробных записей заказа, которые содержат тот же идентификатор заказа, что и FK.
источник
NULL
в одной таблице за несколькоNULL
единиц в другой таблице.1 - Да, хотя бы SQL Server 2000.
2 - Да, если это не
UNIQUE
ограничение или связь с уникальным индексом.источник
Изо рта лошади:
Посмотри это:
Oracle 11g ссылка
источник
Да, внешний ключ может быть нулевым, как сказано выше старшими программистами ... Я бы добавил еще один сценарий, когда внешний ключ должен быть нулевым .... предположим, у нас есть таблицы комментариев, изображений и видео в приложении, которое позволяет комментировать изображения и ролики. В таблице комментариев мы можем иметь два ForeignIs PicturesId и VideosId вместе с первичным Key CommentId. Поэтому, когда вы комментируете видео, потребуется только VideosId, а pictureId будет нулевым ... и если вы прокомментируете только изображение, потребуется PictureId, а VideosId будет нулевым ...
источник
это зависит от того, какую роль это
foreign key
играет в ваших отношениях.foreign key
такжеkey attribute
в вашем отношении, то это не может быть NULLforeign key
нормальный атрибут в вашем отношении, то он может быть NULL.источник
Вот пример использования синтаксиса Oracle:
сначала давайте создадим таблицу COUNTRY
Создать таблицу ПРОВИНЦИЯ
Это прекрасно работает в Oracle. Обратите внимание, что внешний ключ COUNTRY_ID во второй таблице не имеет "NOT NULL".
Теперь, чтобы вставить строку в таблицу PROVINCE, достаточно указать только PROVINCE_ID. Однако, если вы решили указать и COUNTRY_ID, он должен уже существовать в таблице COUNTRY.
источник
По умолчанию нет никаких ограничений на внешний ключ, внешний ключ может быть нулевым и повторяться.
при создании таблицы / изменении таблицы, если вы добавите какое-либо ограничение уникальности или не ноль, то только это не допустит нулевых / повторяющихся значений.
источник
Проще говоря, «неидентифицирующие» отношения между сущностями являются частью ER-модели и доступны в Microsoft Visio при разработке ER-диаграммы. Это необходимо для обеспечения количества элементов между сущностями типа «ноль или более нуля» или «ноль или единица». Обратите внимание на это «ноль» в количестве элементов вместо «один» в «один ко многим»
Теперь пример неидентифицирующих отношений, где количество элементов может быть «ноль» (неидентифицирующий), - это когда мы говорим, что запись / объект в одном объекте-A «может» или «не может» иметь значение в качестве ссылки на запись / s в другой сущности-B.
Так как существует возможность для одной записи объекта-A идентифицировать себя с записями другого объекта-B, поэтому в Entity-B должен быть столбец, чтобы иметь значение идентификатора записи объекта-B. Этот столбец может быть нулевым, если ни одна запись в Entity-A не идентифицирует запись (и), или объект (ы) в Entity-B.
В объектно-ориентированной (реальной) парадигме существуют ситуации, когда объект класса B не обязательно зависит (сильно связан) от объекта класса A в своем существовании, что означает, что класс B слабо связан с классом Такой, что класс А может «содержать» (сдерживать) объект класса А, в отличие от концепции объекта класса В, должен иметь (композицию) объект класса А для его (объекта класса). Б) создание.
С точки зрения SQL-запроса, вы можете запросить все записи в entity-B, которые являются "ненулевыми" для внешнего ключа, зарезервированного для Entity-B. Это приведет к тому, что все записи, имеющие определенное соответствующее значение для строк в Entity-A, в качестве альтернативы, все записи со значением Null будут теми записями, которые не имеют никаких записей в Entity-A в Entity-B.
источник
Я думаю, что лучше рассмотреть возможную мощность в таблицах. Мы можем иметь минимально возможную нулевую мощность. Когда это необязательно, минимальное участие кортежей из связанной таблицы может быть равно нулю. Теперь вы сталкиваетесь с необходимостью использования значений внешнего ключа равными нулю.
Но ответ - все зависит от бизнеса.
источник
Идея внешнего ключа основана на концепции ссылки на значение, которое уже существует в основной таблице. Вот почему он называется внешним ключом в другой таблице. Эта концепция называется ссылочной целостностью. Если внешний ключ объявлен как нулевое поле, это нарушит саму логику ссылочной целостности. На что это будет ссылаться? Это может относиться только к тому, что присутствует в основной таблице. Следовательно, я думаю, что было бы неправильно объявлять поле внешнего ключа пустым.
источник
NULL
, но что говорит ссылочная целостность, так это то, что если он ссылается на «что-то», он должен быть там.Я думаю, что внешний ключ одной таблицы также является первичным ключом какой-то другой таблицы. Так что он не допускает нулевые значения. Поэтому не возникает вопроса о наличии нулевого значения во внешнем ключе.
источник