Конструкция SQL / DB: многостолбильный внешний ключ со смешанным NULL / NOT NULL рассматривается как обязательный или необязательный?

Question

В дизайне БД / SQL теоретически возможно объявить что-то подобное:

CREATE TABLE Groups
(
  round_id    INTEGER  NOT NULL,
  ordinal_nbr SMALLINT NOT NULL,
  PRIMARY KEY (round_id, ordinal_nbr),
  FOREIGN KEY (round_id) REFERENCES Rounds (id) /* irrelevant, just a reference to another table's ID */
)

CREATE TABLE Games
(
  id               INTEGER  NOT NULL IDENTITY,
  round_id         INTEGER  NOT NULL,          /* !!! */
  ordinal_nbr      SMALLINT NULL,              /* !!! */
  scheduled_tipoff DATETIME NOT NULL,
  PRIMARY KEY (id),
  FOREIGN KEY (round_id, ordinal_nbr) REFERENCES Groups (round_id, ordinal_nbr) /* multi-column FK round_id NOT NULL, ordinal_nbr NULL */

)

Теперь вопрос:

Поскольку это необходимо учитыватьСкорее ошибка программирования, что лучше всего приспособить для таких сценариев: рассматривать такие FK как обязательные или считать их необязательными?

Какая здесь логическая политика?

Answer 1

Пока я думаю об этом, мне представляется более целесообразным рассматривать весь ФК как необязательный.Как только одна часть информации отсутствует, независимо от того, предназначена она или нет, весь FK зависит от столбца (столбцов), значение которого не было установлено YET.

В конце концов, значение NULL уничтожает обязательство.Для меня это имеет больше смысла, чем наоборот.

Answer 2

Создайте отдельное поле в таблице групп, чтобы действовать в качестве первичного ключа, и присоединитесь к нему ..

У вас здесь административный кошмар.

NULL<>NULL !!!!!

Если X неизвестен, а Y неизвестен, можете ли вы сказать X = Y?В зависимости от используемой вами БД \ Конфигурации может даже произойти сбой соединения. В моем варианте тот факт, что любая БД позволяет NUll=NULL вернуть True, является ошибкой.

Answer 3

Почему это должно быть ошибкой?

Рассмотрим таблицу Adults и таблицу Offspring, которая ссылается на нее.

(неправильно указано ранее) edit:

Что, если бы был какой-то потомок, о котором вы знали родителей?Просто игнорируйте, что они существуют.

edit:

Это реальный пример, с которым я только недавно столкнулся:

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

'UNKOWN OWNER'

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

Если бы значение было пустым или пустым, это немедленно вызвало бы ошибку, и я мог изменить таблицу в начале дизайна.Кроме того, в агрегатных запросах нули выпадают из объединений, поэтому у вас нет неверных результатов.И когда я хочу их, я просто left join таблицы.

Answer 4

Обнуляемые внешние ключи в SQL имеют множество недостатков. С точки зрения семантического моделирования это вряд ли имеет смысл. Например, предположим, что значение null ordinal_nbr подразумевает, что этот атрибут неизвестен. В этом случае SQL может не оценивать другой атрибут и не будет возвращать ошибку, даже если нет соответствующей строки для известного значения round_id (YMMV в зависимости от СУБД и других параметров).

Я предлагаю вам переработать его так, чтобы исключить все внешние ключи, которые можно обнулять.

Answer 5

Я не думаю, что есть общий ответ на это.В существующих данных есть какие-либо нулевые значения в games.ordinal_nbr?Там может быть код, который ожидает, чтобы иметь возможность поставить нулевое значение, поэтому вы должны проверить весь код, который использует эту таблицу.Еще интереснее то, что разные базы данных справляются с этим по-разному.Некоторые считают, что «null = null» является истинным, в то время как другие считают любой оператор сравнения ложным, если любая из сторон равна нулю, даже если обе они равны.